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(57) A decision support system for the management 
of an agile supply chain that provides an architecture 
including a server side and a client side. The server side 
includes a decision support system database that inter- 
faces with model engine that performs analysis of the 
data to supportn^ahn The server side 

includes a server manager that coordinates requests for 
service and information. The client side includes deci- 
sion frames that present the various view points availa- 
ble in the system to the users. A frame manager 



generic linear programming solvers and statistical anal- 
ysis routines. The system also includes a demand and 
supply reconciliation process reconciling production, 
sales and inventory and reconciling a top-down forecast 
with a bottom-up forecast where an expert bas ed model 



is used for the bottom-up forecast A capacity planning 
process determines the feasibility of a capacity plan 
responsive to supply constraints. A vendor managed 
replenishment process plans inventory replenishment 



analysts and periods responsive to predicted sales and 
coordinates the requestyfrom decision support frames suppfy constraints.- A scenario managemert prbcess" 



to access the needed data and models. The decision 
support frames provide a view into supply chain and 
integrate analytical models responsive to the view point 
of a business process such as demand management 
The frames include a supply management frame, a 
demand management frame, a vendor managed 
replenishment frame, a Planning, Sales and Inventory 
planning frame and a distribution network design frame 
The model engine includes a component procurement 
policy development module, a finished goods distribu- 
tion network design module, an aggregate production 
planning module, a finished goods inventory manage- 
ment module, a sales forecasting and planning module, 
a market data analysis module, a vendor managed 
replenishment module and various utilities such as 



associated with all frames enables the user to analyze 
different hypothetical scenarios for comparison of busi- 
ness plans. The frame manager includes a system inte- 
grator and a functional integrator. A database 
management system manages the supply and mainte- 
nance of information needed by the modeling proc- 
esses through the frame manager. A domain 
management process limits data available to said 
frames responsive to a user selection. 
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Description 

BACKGROUND OF THE INVENTION 
5 ReJd of the Invention 

The present invention is directed to a system tor supporting management decisions associated with manufacturing 
of service supply chains that span from a point of creation to a point of consumption and, more particularly, is directed 
to a system that allows the various decision makers in the supply chain to view the supply chain from their own perspec- 
10 five, obtain information and evaluate decisions concerning past current and future performance with respect to a 
diverse set of often conflicting goals. 

Description Of The Related Art 

is Many types of manufacturing database management and inventory control systems exist today. Each of these sys- 
tems views the process from the narrow viewpoint of the goals of such a system. For example, inventory control proc- 
esses tend to determine when the inventory of an item is projected to be depleted and when to order goods to prevent 
such depletion. The inventory control process does not generally take into account the problems associated with avail- 
ability of materials and machines to satisfy the inventory demand. On the other hand the manufacturing control process 

20 considers the availability problem but does not take into account the effect of a sales promotion that win deplete an 
inventory faster than projected. A marketing department in preparing a sales promotion wiO often not consider the effect 
that promotion win have on availability, inventory and profit margin but tends to focus on sales goals. What is needed is 
a system that will support managers with each of these view points in understanding the effect of the various decisions 
that can be made on the supply chain as a whole both cunentry and into the near futura 

25 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a system that allows a decision maker in a supply chain to view 
the chain from their own perspective and understand the effect that their decisions will have on the supply chain as a 
so whole. 

It is another object of the present invention to provide a distributed and layered architecture that allows the reuse 
of processing resources and data in making diverse different view point decisions concerning a supply chain. 

It is also an object of the present invention to provide a User Interface that projects a view (a Decision Support 
Frame) into the supply chain that takes into account the view point of the particular user, such as a plant manager or 
35 sales manager. 

ft is another object of the present invention to provide quantitative models and analytical processes to support the 
plans prepared and decisions made from the various supply chain view points such that these resources are cost effec- 
tively provided and utilized in across the entire supply chain-wida 

It is also an object of the present invention to provide a scenario management system in which Scenarios can be 
-~4a— savedrmoc5fied and data transferred between view points or frames: 

It is a further object of the present invention to allow the user to specify a data domain that limits the data used tor 
a particular view point 

It is an additional object of the present invention to provide a system that will reconcile the demand and supply 
aspects of a supply chain. 

. 45 It ©still another object of the present invention to allow the aeatic^ 

(PS!) plan and provide a projection concerning what is feasible in the production, sales and inventory plan. 

It is an object of the present invention to allow the manufacturer or vendor to plan the supply of goods and services 
for a customer that integrates all information about a product, including current past and projected future sales and 
inventory, into a feasible replenishment plan. 
so It isa further object of the present invention to provide a planning process that reconciles top down arid bottom 'up 
projections. 

It is an object of the present invention to provide expert based models that allow forecasts from various view points 
including a bottom up view point 

It is also an object of the present invention to operate in an interactive and dynamic decision environment providing 
55 decision support to single or a set of users. 

It is also another object of the present invention to maintain overall data consistency and provide performance feed- 
back to users reflecting the impact of local" decisions on global supply chain performance. 

The above-identified objects can be attained by a decision support system tor the management of agile supply 
chains thai provides an architecture including a server side and a client side. The server side indudes a decision sup- 
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port system database that interfaces with one or more model engines that perform analytical processes on the data to 
determine requirements and make projections The server side indudes a server manager that coordinates requests 
for service and information. The client side indudes Decision Support Frames that present the various view points avafl- 
able in the system to the users. A frame manager that coordinates the requests from Decision Support Frame (vim 
5 points) is provided by the system to access the needed data and models, 

These together with other objects and advantages which wiD be subsequently apparent reside in the details of con- 
struction and operation as more fully hereinafter descried and claimed, reference being had to the accompanying 
drawings forming a part hereof, wherein like numerals refer to like parts throughout 

w BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 DSS System Architecture in the Context of Manufacturing Supply Chains. 

Figure 2 DSS System Architecture in the Context of Equipment Repair Supply Chains. 

Figure 3 Dedsion Support Thread. 
13 Figure 4 The Data Spaces in Supply Chain Management 

Figure 5 Structural Elements in the DSS Database for the Manufacturing Supply Chain. 

Figure 6 Structural Elements in the DSS Database for the Equipment Repair Supply Chain. 

Frgure 7 Specification of Dedsion Support Frame 

Figure 8 Decision Processes in the Manufacturing Supply Chain. 
so Figure 9 High Level Model of an Equipment Repair Supply Chain and the Decision Processes. 

Figure 10 Process and Data Row Diagram Legend. 

Figure 1 1 Data Space Assodations of the Demand Management Frame. 

Figure 12 Process Flow of the Demand Management Frame 

Figure 13 Process Flow of Order Fulfillment 
2$ Fxjure 14 Data Flow tor the Demand Management Frame. 

Figure 15 Data Space Assodations of the Production -Sales-Inventory Planning Frame. 

Figure 16 Process Flow of the Production- Sales-Inventory Planning Frame 

Figure 17 Data Row for the Production-Sales-Inventory Planning Frame 

Figure 18 Data Space Assodations of the Supply Management Frame. 
so Figure 19 Process Flow of the Supply Management Frame 

Figure 20 Data Flow for the Supply Management Frame 

Figure 21 Data Flow for the Supply Management Frame 

Figure 22 Data Space Assodations of the Vendor Managed Replenishment Frame. 

Figure 23 Process Flow of the Vendor Managed Replenishment Frame 
55 Figure 24 Data Row tor the Vendor Managed Replenishment Frame 

Figure 25 Data Space Assodations of the Distribution Network Design Frame 

Figure 26 Process Row of the Distribution Network Design Frame 

Figure 27 Data Row tor the Distribution Network Design Frame. 

Figure 28 Seven Modules and Supply Chain Management 
40— Figure 29 Pareto Analysis for ABC Classification. — ____ 

Figure 30 Scatter Plot for Sales-Volatility Classification 

Figure 31 Impact of Sales Promotion. 

Figure 32 Curve Fitting for Promotion Effect Analysis. 

Figure 33 System Level Services, the Seven Modules and Model Engine Utilities. 
45 Figure 34 Supply Chain-Frame Manager: High Level Architecture. 

Figure 35 High Level Architecture of the System Integrator. 

Figure 36 High level object representation of the system integrator portion of the frame manager. 

Figure 37 High Level Architecture of the Functional integrator. 

Figure 38 Data Row Oiagram for the Supply Chain Network Conf igurator, 
so Rgure 39 Functionality in the Domain Manager. " 

Figure 40 Hierarchical Structure of a Scenario. 

Figure 41 Data Row Diagram for the Performance Simulator. 

Rgure 42 User-DSS Interaction Process. 

Rgure 43 Sample Screen from PSI DSS. 
55 Figure 44 Three-tier Application Development Architecture. . 

Rgure 45 DSS Development Platform Environment 

Rgure 46 Generic System Architecture. 

Rgure 47 System Architecture in View of the DSS Prototype 

Rgure 46 The Logon Dialog Box. 
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Figure 49 The Opening Screen of the DSS. 

Figure 50 User Preferences Selection Dialog Box. 

Figure 51 The Select Data Domain Form. 

Figure 52 Edit Data Domain Dialog box. 
5 Figure 53 Make Product Domain Dialog Box. 

Figure 54 Save Scenario Dialog Box. 

Figure 55 Open Scenario Dialog Box 

Figure 56 Demand Management Bottom Up Forecast Screen. 

Figure 57 Demand Management Top Down Forecast Screen. 
w Figure 58 Promotion Calendar Main Display. 

Figure 59 The Promotion Selection Wizard. 

Figure 60 The Main PSI Frame Form. 

Figure 61 The Options menu choices on the PSI screen. 

Figure 62 PSI Reconciliation Order Dialog Box. 
is Figure 63 The main capacity checking dialog box - The Options tab. 

Figure 64 The Results tab. 

Figure 65 The Production Resource tab. 

Figure 66 The Key Components tatx 

Figure 67 The Bfll of Material tab. 
20 Figure 68 The Alternative Components Tab. 

Figure 69 The Resource Requirement tab. 

Figure 70 Key Component Selection Dialog Box. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

28 

Introdu c tion 

Overview of the DSS Conceptual Architecture 

30 The Decision Support System (DSS) 10 of the present invention (see figure 1) relies on quantitative models and 
data analysis routines to provide decision support Consider for example the production, sales and inventory (PSI) plan- 
ning process. An architecture to provide such stpport in accordance with the present invention comprises a library of 
models and routines that are logically linked, regularly updated and maintained. To support the PSI planning process 
for example, one can then employ an appropriate subset of models and routines from the Itorary to represent the under- 

35 lying supply chain abstraction and provide decision support The present invention assembles the models and routines 
in a flexible manner, as needed by a decision making environment to enable the DSS 10 to provide customized deci- 
sion support with a readOy upgradable and scalable library. 

Printipal Design Elements 



The architecture of the Decision Support System (DSS) 10 for a manufacturing supply chain is shown in figure 1 
and comprises the principal design elements of: a DSS Database 12 with a Database Management System (DBMS) 14 
and Supply Chain Information Systems 15, Decision Support Frames 16 which provides the various supply chain view 
points, a User Interface 18, a Model Engine 20 including various Model Engine Utilities (processes) 22 and a Supply 
45 Chain Frame Manager 24; The archite cture of the DSS 10 in t he con text of an equipment re pair supply chain is illus- 
trated infigure 2. 

Salient Features 

so The DSS architecture comprises two basic mode divisions: the Client Mode 30 and the Server Mode 32. These 
modes can be classified with respect to an implementation of the DSS 10 in a sippty chain. Rom a design standpoint 
the CGent Mode 30 is the portion of the DSS architecture that is specific and therefore customizable to provide decision 
support for any particular decision process and decision maker. The Server Mode 32, on the other hand, is the kernel 
of the DSS architecture that remains largely the same across different applications of the DSS 10 within a given supply 

55 chain. Hence, for a given implementation of the client-server DSS architecture in a supply chain, there win be one 
Server Mode 32 and a number of Client Modes to provide support for the decision processes. 

As shown in figures 1 and 2 the Client Mode 30 comprises the User Interface 18. the Decision Support Frames 16, 
and the client version of the Supply Chain Frame Manager 24. The Server Mode 32 comprises the Supply Chain Frame 
Manager 24, the system level services, the Model Engine 20, and the DSS Database 12. The Supply Chain Frame 
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Manager 24, as a participant in both modes, serves to tie the Client and the Server Modes of the architecture together. 

The dient-server architecture makes the overall design both extensible (new functionality can be added by custom- 
izing a frame in the Client Mode 30) and scalable (new models and routines can be added to the Model Engine 20 in 
the Server Mode 32). Additionally this design is networtable; one can visualize the Server Mode 32 of the DSS 10 
5 hosted by a server workstation in a client-server network while a number of Client Modes 30 of DSS 10 are hosted in 
the client conputers. The layered design of the architecture, in terms of how the principal design elements of the DSS 
10 are positioned within the architecture, provides a more resilient and stable backbone for decision support The high 
level design architecture is independent of any computing and networking platform and hence applicable to a variety of 
environments. 

to The structure maintains the design of the horizontal layers for its key system elements while rts functionality is more 
aligned vertically. The overall DSS 10 interfaces with the Supply Chain Information Systems 15 through the data 
exchanges between these systems and tfie DSS Database 12. The DSS 10 has a User Interlace 18 to interact with end 
users through interactive and visual data exchange Thus, the main body of the DSS 10 includes the following horizontal 
layers: User Interface 18; Decision Support Frames 16; Supply Chain Frame Manager 24 (Client and Server); Model 

is Engine 20; and DSS Database 12 . 

As previously mentioned, the above layers of the DSS 10 can be partitioned into cfient and Server Modes. The sys- 
tem layers within the COent Mode 30 serve an interpretive role between the system data and analytic processing sup- 
port and the specific end user's decision support needs Those layers under the Server Mode 32 contain system 
functionalities common to a diversity of users and decision support problems, and usually require more dedicated, 

20 higher performance system processing capabilities. 

To capture and process a user's decision support request, the DSS 1 0 wiD invoke a vertical decision support thread 
40 going through visual objects of a User Interface 18. decision logic and what-rf scenario manager in a Decision Sup- 
port Frame. Supply Chain Frame Managers, models or analysis routines in the Model Engine 20 and appropriate data 
elements in the DSS Database 1 2. An example of a decision support thread 40 is shown by the bi-directional arrows in 

25 figure 3. 

Relevant Supply Chains 

The detailed discussion and specifications for the Decision Support Frames 16 provided in this document are 
30 generic in nature so that the functionality and system features in the resulting DSS 10 can cover decision environments 
for a diversity of supply chains. The system specifications and descriptions in this document address the two distinctive 
supply chains previously mentioned: I. Manufacturing: Finished goods are produced from raw materials, components, 
and subassemblies using resources (e.g.. humans and machines) distributed to the demand points, and consumed by 
the end users. Material flow can be characterized as linear. II. Equipment Repair: Ruled items are sent to the repair 
35 facilities, repaired using resources (ag., humans and test equipment), and restored to usable condition. Material flow 
can be characterized as reentrant 

Even though a typical manufacturing environment may perform a limited amount of repair operations, such as 
machine maintenance or product service, its resources are predominantly dedicated to material procurement finished 
goods production and distribution. In this view, the distinguishing characteristic between the manufacturing and repair 
^ envronments is the degree to whi^trte~e^ronment focuses on theproductwnof new goods versus tfmepair of old 
ones. Corrpared to the manufacturing supply chain, the equipment repair supply chain has complex reentrant flows, 
while the manufacturing is characterized by the linear material flows from material procurement to final consumption. 

DSS Database 

Overview 

The DSS Database 12 is internal to the DSS 10 implementation. The main objective of the DSS Database 12 is to 
support the execution of the decision support functionality of the DSS 10. ft contains tiie synthe^ed dafa dr^ from 

so a variety of external supply chain ta^ 

a set of data unique to the DSS 10 but not available in any existing Supply Chain Information Systems 15. An example 
of such unique data is the data derived through the analysis of synthesized data. The DSS Database 12 can be inter- 
faced to the Supply Chain Information Systems 15 to retrieve the required data and provide updated data, as needed. 
The Database Management System 14 (DBMS) communicates with the Model Engine 20 to provide the input data. 

55 and update the database 12 based on the output of the Model Engine 20. In general the DBMS 14 does not duplicate 
the transaction-based functionality that is typically featured in the Supply Chain Information Systems 1 5, unless it is crit- 
ical for decision support needs 
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Data Representation Schema 

Choosing an appropriate data representation is important to ensure data consistency, and reoonfigurability. 
5 Structural Data Representation 

A structural data representation of the data in various data spaces 50. 52 and 54 (see figure 4) is used to model 
the dements of the supply chain that are relatively static. Specifying these data elements typically specifies the infra- 
structure of the supply chain. At the highest (eve! of abstraction, four principal nodes (see figures 5 and 6) in the supply 
to chain 58 are identified: 

Demand node 59: The customer demands are characterized at this node. 

Inventory Node 60: Inventories of Key components or finished goods are identified to be at these inventory nodes. 
Production Node 61 : Production resources (or finished goods supply) are located at production nodes. 
15 Component Supply Node 62: The supply points of key components are characterized at the component supply 
nodes. These structural data elements are spatially distributed along the supply chain 58 (see figure 5). The rela- 
tionship between these nodes is preferably modeled in the form of a network. The network characterization is a col- 
lection of finks that connect the principal nodes. A link establishes a logical relationship between two nodes, which 
may have several attributes such as distance between the two nodes* transportation lead time, etc 

20 

In greater detail, the structural data elements and their relationship to the principal nodes are descrbed as follows. 
Key components 63 are supplied by component suppliers 64 tied to specific component supply nodes 62. Production 
resources 65 produce the various products 66. The production resources can be aggregated into production resource 
groups 67. and are located at production nodes 61. Products 66 are the end Herns that are produced and. based on 

25 their various attributes, can be grouped into various product groups 67. These products are stocked at various stock 
locations identified with inventory nodes 60 and inventory headers 68. Customers 69 can be grouped by various criteria 
into customer groups 70 and demand various products. Customers 69 are located at the demand nodes 59. Markets 
71 are defined for a cross-section of customers and products. 

A similar structure can be provided for the repair chain as illustrated in figure 6. 

30 Such a data representation in the form of a network of nodes and the ability to group the various constituent ele- 
ments, provide the flexibility to specify and reconfigure a variety of supply chains. 

Process Data Representation 

35 In addition to the structural elements, the data associated with the various processes in the supply chain need to 
be represented. These process data elements are relatively dynamic with respect to time and the associated processes 
transform data related to the various structural elements. To characterize the process data, we introduce a few addi- 
tional data structures. 

40— Data Space 

A data space is a fundamental domain to characterize basic data elements associated with the supply chain man- 
agement demand, supply and inventory data. The data spaces 50, 52 and 54 tie the structural data to the process data. 
It has three principal dimensions: Product/Component; Time; and Node related structural element. As the node-related 

m -tfructuraLele^ anjnventory ^location, or a production resource. The data in each data space can- 
be at any resolution (in terms of level of aggregation) along the three dimensions and can be expressed as a quantity 
or value. Thus, each point in the data space characterizes the resolution of the product (or component), the time and 
the node-related structural element. For example, when describing the aggregate production plan data, a product can 
be at the resolution of product time at a resolution of week, and the node-related structural element (Production 

so resource in this case) at a resolution of production resource group. On the other hand~ in describing bottorn-up fore- 
casts, a product can be at the resolution of product time at a resolution of month, and node related structural element 
at the resolution of customer. 

We identify three principal data spaces associated with supply chain management: Demand Data Space 50: Inven- 
tory Data Space 52: and Supply Data Space 54. These data spaces are pictorially represented in figure 4 and are 

55 explained next. 

Demand Data Space 50: This data space 50 has three dimensions: Customer: Product and Time. Customer can 
be at a resolution of customer or customer group or demand node. Product can be at the resolution of product or prod- 
uct group. Time can be at a resolution of day, week, bi-week, month, bi-month. quarter or year. 

Supply Data Space 52: This data space 52 has the following three dimensions: Production Resource; Prod- 
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uct/Conponerrt; and Time. Production resource can be at a resolution of production resource, production resource 
groups or production node. PrcxJuctfCorrponent can be at the resolution of component product or product group. Time 
can be at a resolution of day, week bi-week, month, bwnorrth, quarter or year. 

Inventory Data Space 54: This data space 54 has the following three dimensions associated with it: Inventory Loca- 
5 tion; Product/Component; and Time. Inventory location can be at a resolution of stock location or inventory node. Prod- 
uct/Component can be at the resolution of component, product or product group. Time can be at a resolution of day, 
week bi-week, month, bi-month, quarter or year. 

A decision process relates or transforms data either within a data space or between data spaces. For example, 
aggregate production planning transforms data from the supply space to inventory space and vice versa. We will 
to employ this data space representation to specify the various decision processes in supply chain management 

The DSS Database 12 comprises structural information (information related to relatively static information such as 
product groups, market groups, supply chain network etc.). and process infor mation (dynamic information related to 
demand, production plan, etc). Figure 5. previously discussed, graphically represents the structural data tables for the 
manufacturing supply chain. 

is SimOarty. the DSS Database 12 for the equipment repair supply chain (see figure 6) comprises structural informa- 
tion (information related to relatively static information such as equipment repair resources, supply chain network etc), 
and process information (dynamic information related to usage, requirements, repair plan, etc.). Again, the structural 
elements are flexibly collected into different groups to allow users to analyze data at various resolutions. For example, 
equipment of the same age can be grouped together to analyze the effect of age on repair requirements. Figure 6 

20 graphically represents the structural data tables for the equipment repair supply chain. 

The process data in the DSS Database 12 are contained in two closely related table type data structures (see 
below): (I) header fOe that specifies the resolutions and values on the relevant dimensions of product, customer, time, 
resource, and item, (a) corresponding data fOe which contains the actual data at the resolutions and values specified in 
the header. The process data are preferably stored in these two tables (Table 2, Table 3), rather than one consolidated 

25 table (Table 1). to avoid redundancy and updating anomalies. A loss-less join of the header and the data tables will 
result in the consolidated table (Table 1 ). The following example demonstrates this point 
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Table 1 

A single consolidated table with redundancy (not in normal form) 
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Table 2 

Header table that provides the series information 
and the various identifiers 
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Table 3 

Data table that contains references to the header table 
and the time series data 



Data tables 

The data tables in the DSS Database 12 are preferably specified as follows: Name of the table; Brief description of 
the data contained in the table; Identifier for the data fields; Type of the data field; and Brief description of the data fields 
(this indudes the choice of values for the data in this field, if applicable). 

The specifications of the data tables tor the manufacturing and equipment repair supply chains can be found in 
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Appendices A and B» respectively. The Dst of the preferred tables in the OSS Database 12 for these chains is as follows: 
Aggregate Production Plan Data; Aggregate Production Plan Header; Budget Data; Budget Header; Calendar; Com- 
ponent; Componoit A c co mm odation Matrix; Component Requirement Data; Component Requirement Header; Com- 
ponent Supplier; Component Supply Contract; Component Supply Node; CPRD Table; Customer; Customer Group; 
Customer Group; Definition; Customer Orders; DataReld Definition; Demand History Data; Demand History Header; 
Demand Node; Demand Orientation Data; Demand Orientation Header; Domain; Domain Definition; Feature Choices; 
Forecast Data; Forecast Header; Freight Rate; Inventory Data; Inventory Header; Inventory Node; Inventory Parame- 
tm; Market Data; Market Header; Material DeOvery Schedule Data; Material Delivery Schedule Header; Planning 
BOM; POS Data; POS Header; Product; Product Features; Product Group; Product Group Definition; Production 
Accommodation Matrix; Production Capacity Data; Production Capacity Header; Production Matrix; Production Node; 
Production Requirements Data; Production Requirements Header; Promotion Data; Promotion Header; Resource; 
Resource Group; Resource Group Definition; Sales Requirements Data; Sales Requirements Header; Scenario; Sce- 
nario Data; Compatibility; Scenario Definition; Setup Matrix; Supply Chain Network; Supply Order Data; Supply Order 
Header; Temporary Product List; VMR Contract; VMR Data; and VMR Header 

Core Reports 



The present invention preferably provides core reports that support business decision processes by characterizing 
the link between the various data elements and processes. They synthesize the data and information used in the ded- 
20 sion making processes. Associated with each key business process, we wifl demonstrate the data flow relationships 
that are used to construct the various forms and reports. Some of the preferred forms and reports relevant to the DSS 
10 are: Sates Plan; Customer-Demand History; Production-Sales- Inventory Plan; Master Production Plan; Production 
Capacity Plan; Replenishment Schedule; Customer-DC Assignment; and Supply-DC Assignment 

25 Decision Support Frames 

Overview 

From a user perspective, a Frame 16 is an integrated decision support environment based on an abstraction of the 
30 supply chain designed to address a set of related decision problems within a decision process. A Frame 1 6 is therefore 
defined based on the vantage point or view point of the users along a supply chain. This implies that a frame exists if 
and only if there are users with specific needs in the supply chain. 

From a system perspective, a Frame 16 is a mechanism that unifies the user dialog and display, the models and 
analysis routines, and data in a manner that is consistent to support the underlying supply chain abstraction of the use-. 
35 A summary of the frame concept from both a user and a system perspective is shown in Table 4. 
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User Perspective 


System Perspective 


An environment to address 
a collection of related 
decision problems. 


It is a subsystem that 
processes user requests in 
the form of Scenarios. 


Always associated with a 
decision maker or a group 
of decision makers* Frame 
exists if and only if 
there are decision makers. 


It consists of a 
consistent set of process 
and data models. 


Has a unique perspective 
of the underlying supply 
chain based on the 
responsibility of the 
decision makers associated 
with the frame. 


It unifies the User 
Interface, Model Engine, 
and DSS Database elements 
that are specific to a 
decision making process. 


Enhances the coordination 
of decision making 
implicit in the definition 
of the frame. Enforced 
through organizational 
accountability and 
responsibilities . 


A convenient client -server 
architecture that enables 
the extension of the DSS 
functionality. j 



Table 4 

Frame Concept: User's and System Perspective 



Frame Architecture 

The high level design of a Decision Support Frame 16 and its interaction with the User Interface 18, the Supply 
Chain Frame Manager 24, the Model Engine 20, and the Database 12 is illustrated in figure 7. A Frame 16/72 is the 
abstraction of the supply chain from a user's point of view. It essentially contains as its design elements a user dialog 
72 and user display 74 and a decision logic 76. The user dialog 73 and the display 74 contain the form and style of the 
User Interface 1 8. The decision logic 76 permits the assembly of models and analysis routines and the associated data 
to address the set of related decision problems. For example, in the case of the PSI Planning Frame 1 60, the user cfia- 
log 72 and display 74 are customaed to the specific needs oTthe PSI planning process." which^ 
design of the User Interface 18 associated with the PSI Planning Frame 160. Users will interact with the PSI Planning 
Frame 160 through the User Interface 1 8 by formulating Scenarios 78. Based upon the Scenarios 78, the decision logic 
76 in the PSI frame may assemble models and routines from the Model Engine 20 along with the associated data The 
decision logic 76 in a frame interacts with the Supply Chain Frame Manager 24 to execute the models and routines. The 
-Supply Chain Frame Manager 24 then provides the performance feedback to the user. 

Decision Processes in the Manufacturing Supply Chain 

The decision processes in the manufacturing supply chain are depicted in figure 8. We have identified five decision 
processes closely associated with the key decision makers arid potential users in a supply chain: Overall Supply Chain 
Management 80, Demand Management 81. PSI (Production -Sales- Inventory) Planning 82, Supply Management 83. 
and Vendor Managed Replenishment (VMR) 84. 

Overall Supply Chain Management 

A supply-chain -wide view and the necessary Management 80 is recognized by all levels of the management as 
being vital to managing the business. However, decision makers at different levels and points along the supply chain 
are primarily motivated by their individual roles and responsibilities. The broader a decision maker's responsibilities, the 
more likely the decision maker is interested in errptoying decision support capabilities that target the entire supply 
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chain. The user requirements discussed below tor decision support are posed from a supply-chain-wide perspective. 
Given the uncertainty in the medium* to long-term sales forecasts, determine whether or not the enterprise should 
expand, maintain or reduce its production capacity and/or stocks for the critical components. When changes in busi- 
ness conditions impact one part of the supply chain, assess the potential impact on the other parts of the supply chain. 
Given different future business scenarios, determine their financial consequences across the supply chain. For the 
enterprise's supply chain which includes major retailers, determine the appropriate division of responsibilities for all 
partners in the supply chain. Develop and implement performance incentives that will enhance and encourage supply* 
chain-wide thinking and decision making in the enterprise- 
Demand Management 

Demand Management 81 is the process by which the customers' requirements are characterized with the specifi- 
cation of prevailing uncertainty. The process involves the development and maintenance of medium-term customer 
(bottom-up) forecasts. These forecasts are initially developed in periodic joint meetings or communications between the 
decision makers of the enterprise and the customers. Subsequently, these forecasts are input into the enterprise's sup- 
ply management system to obtain product allocation approval (place-keeping order). As the actual purchase orders 
arrive, the enterprise attempts to fulfill the requirements to their customers' satisfaction. We have identified the user 
requirements discuss below tor decision support for this process. Synthesize information from different sources in order 
to manage the demand requirements effectively, ag.. accessing point-of-sales (POS) data and comparing these with 
shipment history and customer forecasts. For key customers, develop customer-specific sales forecasts based on his- 
torical shipment and sell-through data. Link POS data, where available, to the historical promotion information to ana- 
lyze the real impact of promotion activities on demand, as opposed to relying on the estimates provides by the retailers. 

PSI Planning 

PSI Planning 82 is a process to determine a set of feasible sales, production and inventory requirements for 
medium to long-term capacity and resource planning for the logistics operations. At the beginning of each fiscal year, 
an initial PSI plan can be developed based on the long-term top-down sales forecast and budget plans. The planning 
process then becomes a continuous effort to update the existing PSI plan to acc omm odate the changes in the require- 
ments before and after a series of monthly PSI planning meetings whose participants include decision makers repre- 
senting all key functional areas at the enterprise. The meetings integrate the inputs from various sources, resolve 
possible conflicts, and balance the concerns of different functions in order to reconcile, develop and approve a new set 
of feasible sales, production and inventory requirements. The process represents a focal point for the entire logistics 
planning process, and interacts and coordinates with all major decision making processes. We have identified the user 
requirements discussed below for decision support for this process. Generate market trend forecasts by product cate- 
gories for the enterprise as wea as the entire industry. Such forecasts will be based on available shipment history, indus- 
try survey data and influential economic indicators. Generate forecasts for new products and managing product 
transitions. Facilitate development of medium-term top-down and bottom-up sales forecasts for the enterprise. Facilitate 
development of production plans and the associated requirements plans for critical components. Evaluate the effects 
"and uriderstarif the im# resolution median isms 

are needed to adapt and maintain these plans. Identify those products that would be affected by the shortage of certain 
critical components; one possible approach is to use an implosion tool on the bill of materials. Provide a formal mech- 
anism to determine and readjust appropriate inventory levels for various products. 

Supply Management — — — 

Supply Management 83 is a process to determine the production (supply) plan to meet the production (supply) 
requirements generated by the PSI Planning process. The process involves component procurement and factory pro- 
duction planning based on the PSI plans and their changes. At the beginning of the process, the production line capac- 
ities are created based on long-term product plans, i.e.. planned new product release. The process continuously 
updates the production (supply) plan based on changes in the production (supply) requirements generated in the PSI 
process. We have identified the user requirements discussed below for decision support for this process. Determine the 
feasMity and the economic viability of changes in the production (supply) plan, when changes occur in the PSI plans. 
This requirement is motivated by trade-offs between the PSI process and the production (supply) planning process. 
Evaluate possible options to accommodate changes in the production requirements, after the line structure and capac- 
ity are determined. Such an analysis is a requirement of the factory planner. Develop an aggregate level representation 
of the production line capadties so as to help the planners in developing aggregate production plans or checking pro- 
duction capacity. Develop a rough-cut analysis capability to assist the planners in translating the production require- 
ments into critical component requirements, Le.. components featured in the planning bill of materials. 
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Vendor Managed Replenishment (VMfl) 

VMR 84 is a process in which the supplier takes on the responsibility of managing the inventory at the customer 
site for the products H supplies This process operates on point-of-sales demand as opposed to demand forecasts pro- 

5 vided by the customers. VMR involves formulating the contractual agreements between the enterprise and the retailers 
as well as determining the operating parameters such as shipment quantities and replenishment frequencies. We have 
identified the user requirements discussed below for decision support for this process. Develop a strategic analysis tool 
to determine mutually beneficial VMR contracts based on financial and logistics factors. Develop the replenishment 
plan based on factors such as sen-through and inventory information provided by the retailer, promotion activities, prod- 

ro uct availability and transportation cost trade-offs- 

Decision Processes in the Equipment Repair Supply Chain 
Overview of the equipment repair supply chain 

15 

The equipment repair supply chain 90. as depicted in figure 9. includes the operating location 92, i.e.. the potnt-of- 
use. the repair shop 94, and the component suppliers 9a In an equipment repair supply chain, the demand (or the 
"requirements") are generated by equipment failures. When equipment fails, the failed module is replaced from the 
stock at the operating location 92. and the faded module is eventually sent to the repair shop 94 tor repair. A module is 
20 made up of repair items which in turn are made up of components. At the repair shop 94, the repair is carried out by the 
repair resources (people and machinery). During the repair process at the repair shop 94, certain repair items and com* 
ponents are replaced. Based on the repair needs, repair items and components will be ordered from the sources of sup* 
ply by the repair shops. 

Equipment Operating Location 92: At the equipment operating location 92, personnel may replace only certain 
25 repair items of the module, instead of the whole module These replacement repair items may come from the stock or 
from other failed modules. This process encourages consolidation of tailed modules at the operating location. In the 
consolidation process, the broken repair item of a broken module is replaced by a good repair Hem from another broken 
module. This process may be motivated by the structure of the repair cost function and the need for quick repair. In 
some cases, due to the fixed costs of sending individual modules to the repair shop, modules are batched to a certain 
30 level, before they are sent to the repair shop for a complex overhaul 

Repair Shop 94: The repair shop 94 is responsible for all the major repairs. The type of repair to perform is driven 
by the level of good modules at the repair location. When good modules are sent from the repair shop to the operating 
location, the stock level may drop below the target level, thus triggering a repair request to bring the stock level up to 
the target level. This target level is determined with the objective of maximizing the equipment availability and minimiz- 
es ing the repair costs. Component and capacity requirements corresponding to a repair request should be feasible with 
respect to component availability and resource capacity levels at the repair shop. 

Parallel with the manufacturing supply chain: 

40 We recognize the operational differences between manufacturing and equipmem repair supply cr^ 

the equipment repair supply chain has dear parallelism with the manufacturing supply chain where the repair items cor- 
respond to products and components correspond to materials. Equipment operating locations are similar to retailers 
and equipment is like customers. The repair shop is analogous to a production facility. As modules are made up of 
repair items, modules correspond to product groups The repair requirements management process is analogous to 

45 ._ demand management, and repair supply management to supply management Similar to the PSI process, there exists 
a reconciliation process in the equipment repair supply chain to ensure balance between requirements and supply. 

Application to a national defense application 

so For a national defense application, the following nomenclature is used. The equipment located at various operating 
locations are the aircraft operating at the various bases. The modules correspond to the Line Replaceable Units, or 
LRUs and the repair items correspond to Shop Replaceable Units (SRUs). The failure of an LRU, caused by the failure 
of its SRU, renders the aircraft unavailable. The function of the base is to provide immediate support to the aircraft 
located at that base, with the objective of maximizing availability of aircraft For that purpose, bases stock good units of 

55 replaceable items, called serviceabf es, so as to be able to replace a failed LRU of an aircraft immediately. A base, usu- 
ally, is not involved in major repairs. Instead, it implements a consolidation policy (replacing the defective SRU of a 
newly tailed LRU with a good SRU of an already defective LRU), which gives the base the ability to manage the repair 
requirements of the depot Managing the repair requirements refers to deciding when and which defective items the 
base will send to the depot for repair with the objective of maximizing the availability of aircraft located at the base and 
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minimizing total cost of repair (which includes a fixed cost component). 

A depot is responsible to afl the major repairs. The type of repair to perform is driven by the level of good repairable 
items at the depot When good repairable items are sent from the depot to the base, the stock level may drop below the 
target level, thus triggering a repair request to bring the stock level up to the target level. This target level, also called 
the Consolidated Serviceable Inventory (CSQ level, is determined by the depot with the objective of maximizing its serv- 
ice level and minimizing its repair costs. Component and capacity requirements corresponding to a repair request 
should be feasible with respect to component avaflabiDty and resource capacity levels at the depot 

Table 5 below presents the analogy and nomenclature between the equipment repair simply chain, and the manu- 
facturing supply chain with examples from defense and commercial environments. 



Equipment 
Repair Supply 
Chain 


Example 
Defense 
Equipment 
Repair Supply 
Chain 


Example 
Commercial 
Equipment 
Repair Supply 
Chain 


Parallel with 
Manufacturing 
Supply Chain 


Equipment 


Aircraft 


MR I Machine 


Customers 


Module 


tRti 


Cabinet 


Product Group 


Repair Item 


LRU / SRU 


Circuit 
Boards 


Product 


Component 


Bit and piece 
part 


tc 


Component 



Table 5 

Analogy and nomenclature between equipment 
repair and manufacturing supply chains 



Decision Processes in the Equipment Repair Stpply Chain 

The supply chain comprises (see figure 9) the following three decision processes: Requirements Management 
Process 98; Requirements-Supply Reconciliation Planning Process 100; and Supply Management Process 102. 

Requirements Management Process 

The Requirements Management Process 98 concentrates on the activities associated with requirements estima- 
tion. The objective of this process is to estimate future repair requirements generated by equipment failures, Equipment 
" hassevera^lre^ 

future requirements refers to the process of estimating failures of the equipment and of the repairable parts that caused 
the failures. This is done to estimate repair time requirements (determined in Requirements-Supply Reconciliation 
Planning Process) and equipment availability at equipment locations, both of which depend on the part that has failed. 

Requirements can be analyzed in two levels: Lower level requirements, called the Raw Requirements, correspond 
- to aU repair requirements oHhe equipment and upper level requirements, called the Consolidated Requirements, cor^ 
respond to requirements requested from the repair shop, since equipment locations may prefer accumulating their 
repair requirements and sending them to the repair shop according to certain rules instead of sending them as they 
occur, or may prefer carrying out minor repairs within the location, with the aim of reducing the fixed and variable costs 
of repair. In the manufacturing analogy, raw requirements would correspond to Point of Sales (POS) data and consoli- 
dated requirements to retailer order data from the production facility. 

Two different estimation approaches that have been used in this process to estimate consolidated requirements 
are: Bottom-tp Estimation Approach; and Top-down Estimation Approach. 

The bottom-up estimation approach estimates the raw requirements first and then generates the consolidated 
requirements from raw requirement estimates. In order to estimate raw requirements, relationships are determined 
between failure rates and activity schedules of the equipment For example, the time to failure of an equipment can be 
a function of the number of hours it has operated and its maintenance schedula Once the relationships between failure 
rates and activities are established by regression or time series models, future failure rates can be estimated based on 
the planned activity schedules of the equipment Given the estimated raw requirements, the next step is to go to the 
upper level and estimate consolidated requirements, that is requirements as seen by the repair shop (assuming that 
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repair shop does not have access to raw requirements data). Consolidated requirements depend on what frequency the 
operating location wiO send its repair requests to the repair shop. This is analogous to the inventory replenishment pol- 
icy erf a retailer in a manufacturing system. In decking on the type and parameters of the inventory replenishment policy, 
the facility wiO use several conflicting performance measures such as minimizing total repair cost and maximizing avail- 
ability of the equipment Thus, given the inventory replenishment policy of the facility and estimates of its raw require- 
ments, its consolidated requirements can be estimated. 

The top-down estimation approach makes use of historical data to estimate consolidated requirements. Statistical 
forecasting techniques can be used to support this process. 

The two estimates obtained by bottom-up and top-down approaches are compared, analyzed and reconciled to 
generate final estimates for consolidated repair requirements. The output of this process is the estimated consolidated 
requirements for an equipment operating location. 

Requirements-Supply Reconciliation Planning Process 

The second process is the Requirements-Supply Reconciliation Planning process 100 that aims at developing an 
integrated repair plan for the repair shop through a reconcffiation process. First, the type and parameters of the repair 
policy of the repair shop are to be determined. Aggregate repair requirements are generated based on the repair poficy 
of the repair shop and estimated consolidated requirements for all facilities. The next step is to generate an aggregate 
repair plan based on repair time estimates for each repairable part and the aggregate repair requirements. FeasfoOity 
of the aggregate repair plan is checked with respect to resource constraints which are repair resource capacities and 
key component availability, if the aggregate repair plan is not feasible with respect to resource constraints, then causes 
for mfeastoiTrty are identified and the infeasibifity is removed by either changing the level of the resource constraints or 
moving aggregate requirements forward or backward in time. This procedure is repeated until an aggregate repair plan 
that is feasible with respect to resource constraints is attained. The supply management 1 02 (see figure 9) is a process 
to determine the repair plan considering repair people, test equipment and key components. It starts by the translation 
of the aggregate repair plan into a detailed plan concerning repair resources (repair persons and test equipment), and 
component requirements. Based on these requirements and the capacity constraints for the repair resources, repair 
personnel and key components, a detailed repair plan is developed using an optimized based modeling approach. The 
detailed repair plan is used to generate the key component delivery schedule to be transmitted to the component sup- 
pliers. In addition, the supply management process 102 is also concerned with the development of appropriate procure- 
ment policies for key components in terms of identifying the policies, and deriving the corresponding policy parameters. 

Basic Frames 

The basic Frames 1 6 of the present invention collectively provide coverage for the overall supply chain. The specific 
instances of these Frames 16 in a particular OSS 10 implementation depend largely on the constituent supply chain, 
the underlying business processes, and the organizational structure. Table 6 below lists the Decision Support Frames 
16 in the context of manufacturing and equipment repair supply chains. 
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Manufacturing Supply cuain 


Equipment Repair Supply 
Chain 


Demand Management 


Requirements Management 


PS I Planning 


Requirements -Supply 
Reconciliation 


Supply Management 


Supply Management 


Vendor Managed 
Replenishment 




Finished Goods Distribution 
Network Design 





Table 6 

Decision Support Frames in the Context 
of Manufacturing and Equipment Repair Supply Chains 



25 Specification of the Basic Frames 

To specify each basic Frame 16, we use influence diagrams to map the modules in the Model Engine 20 and the 
Data Spaces to the frame We use process flow diagrams to outline the high level design of the logical relationship 
among the key data tables, the modules and the basic Frames 16. We also discuss how to support key functional 
30 requirements in each frame To complete the specification of the basic Frames 16. we use data flow diagrams to map 
the data tables to the core reports in each frama The legend tor the process and the data flow diagrams which will be 
discussed herein after is shown in figure 1 0. 

Demand (Requirements) Management Frame 

35 

The Demand Management Frame 130 supports the demand management decision process described here 
Manufacturing Supply Chain 

40- Module and Data Space Association 

Figure 1 1 shows the participating modules and the associated data spaces for this frame. 
The Demand Management Frame 130 requires the participation of two modules: the Sales Forecasting and Plan- 
ning (SFP) Module 132 and the Market Data Analysis (MOA) module 134. The SFP Module 132 in the Demand Man- 
45 _ agement Frame 130 essentiafly operates in the O data space, Le.. it tran sforms data w it hin the conceptual demand data 
domain. The MDA Module 134 in the Demand Management Frame 130 operates in the I and the 0 data spaces and 
relates the I data space to the D data space, i.e., it may transform data within the individual D data space as wefl as 
transform data from the I data space to the D data spaca The data space representation of the Demand Management 
Frame 130 is the union of the data space representations of each participating module, and the interactions among par- 
so ticipating modules. 

The high level representation of figure 11 can be corrplemented by the process flow diagram for this frame, 
described next, that will detail the connections between the constituent modules and the associated data tables. 

Process Flow 

55 

The process flow diagram for the Demand Management Frame 130 is shewn in figure 12. The modules, data 
tables, and the principal activities within the scope of this frame are clearly marked by the grooved double-lined border. 
Only the data tables that are updated by the frame are considered to be within the scope of the frame 130. Other 
frames, activities and data tables that are related are also shown for completeness. The Order Fulfillment 149, that is 
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out-of -scope of the Demand Management Frame 1 30 but related to it is shown separately in figure 13 for purposes of 
clarity. This representation of interaction between Frames 16 is consistent with the interaction between decision proc- 
esses shown in figure & 

The Demand Management Frame 130 supports the functional requirements described below. Demand Character- 
ization - Demand data from various sources such as Demand History Data 1 36. POS Data 1 3a Market Data 1 40, and 
Promotion Data 1 42 as well as top-down and bottom-up Forecast Data 1 46 obtained by buyers and account managers 
will be consolidated and synthesized by the MDA Module 1 34 and the SFP Module 1 32. Bottom-up Demand Forecast- 
ing - Demand Review 144 consolidates demand information received directly from the customer along with the input 
from the MDA Module 134 and then develops Demand Orientation Data 14a The SFP Module 132 wfll then use 
Demand Orientation Data 148 as well as other inputs. e.g. Promotion 142 and POS 138 Data, to develop the customer- 
centric bottom-up forecasts in Forecast Data 146. Top^lown Forecasting - The SFP Module 132 will use market and 
industry-wide trend analysis performed by the MDA Module 1 34 along with the enterprise's shipment history to gener- 
ate the product-centric top-down forecasts in Forecast Data 146. Sales Promotion Analysis - The MDA Module 134 
reviews the demand history from POS Data 138 and Demand History Data 136 along with the customer promotion 
information from Promotion Data 1 42 to analyze the impact of promotions on sales. The results of such an analysis are 
then used to help adjust sales forecasts to account for promotions. Forecast Performance Evaluation • Using Demand 
Orientation Data 146. Demand History Data 136 and Promotion Data 142. the SFP 132 and MDA Module 134 can eval- 
uate the quality of enterprise's forecasts and the customer projections. 

Data Flow 

The data flow diagram for the Demand Management Frame 130 is shown in figure 14. The Demand Management 
Rama 1 30 generates two of the core reports listed earfier, namely, the Sales Plan 1 52 and the Customer-Demand His- 
tory 1 54. Fbr each core report, the associated data tables are shown. The dashed line indicates the influence of an out- 
of-sccpe (with respect to the Demand Management Frame 130) data table in the development of the report For exam- 
ple, the Customer Orders data table 150 is outof-scope of the Demand Management Frame 130 but influences the 
Customer-Oemand History report 152. 

Demand Management is the process in which the user determines future requirements based on past requirement 
history and general information related to the supply chain. In the context of the manufacturing environment Demand 
Management supports the analysis of past demand and of market trends as wefl as the development of future forecasts. 
For the repair environment the term Requirement Management is used in place of Demand Management Requirement 
Management is the process where future requirements are estimated based on an analysis of each equipment's activity 
and on the projection of past requirement history. 

In the manufacturing context Demand Management regroups the set of processes by which the user analyzes 
Market Data 140 and past demand history tor the purpose of estimating future demand requirements. The outputs of 
Demand Management include the analysis of past history, future forecasts, the analysis of special activities such as 
sales promotions, and the analysis of forecast errors. Two critical outputs of Demand Management are two different 
medium term forecasts corresponding to two Afferent views on the dynamics of the processes that generate future 
req uirements: the customer centric forecast - genera ted at t he product level for e ach customer it in cor porates the esti- 
mations of future demand provided by each customer (Bottom-up Forecast); and the product centric forecast - gener- 
ated at the product level, it incorporates the impact of market and industry-wide trends on future demand for each 
product group (Top<lown Forecast). These two types of forecast are generated using: Historical projection of past 
demand; Future orders information; Analysis of the dynamics and characteristics of the overall market and main com- 
petitors; and Analysis of the impact of future special commercial activities such as sales promotions. These analyses 
- and projections are grouped In five functional requirements that are detailed in the rest of this section: Oemand Char- 
acterization. Bottom-up Demand Forecasting, Top-down Demand Forecasting. Sales Promotion Analysis, and Forecast 
Performance Evaluation. 

Other frames such as production, sales and inventory (PSI) or vendor managed replenishment (VMR) may directly 
or indirectly use the output of Demand Management . . . . 

Demand Characterization 

The objective of Demand Characterization is to provide the user with an environment where (s)he can access, ana- 
lyze and synthesize demand data from different sources. These data include: Sales History data (that include POS and 
shipment data). Inventory data (relative to the inventory position of its product at the customer's stocking points), and 
Market Data 1 40. Market Data 1 40 correspond to various quantitative information, usually provided by external entities 
such as Nielsen, that relates to the sales for the type of product considered in the entire market. 
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Acquire, Display; Edit Data 

Data Acquisition consists of selecting a Data Domain (specific pairs of customer and product), and choosing the 
type of data to be displayed (POS, demand history, inventory, Market Data 140). Data can be edited and modified and 
5 saved along with results of analysis in a scenario. 

Analyze & Synthesize Data 

Sales History and Customer Inventory Data 

to 

This involves the operations discussed below. 

Compute, display (tables and graphs), characterize and analyze sales history per product/|product group or cus- 
tomer/customer group (see the MDA Module specification discussion for details of models and formulas): Volatility of 
demand, Lumpiness of demand. Trends in demand history. Demand pattern changes, and Seasonality. 
is Compute, display (tables and graphs) and analyze sales history statistics for different levels of aggregation: This 
year vs. last year, Actual sales vs. budget and Year to dale vs. balance of Year. 

Compute, display (tables and graphs), and analyze trend in Demand Product Mix by product group. 

Pareto analysis of sales (or inventory) to identify ABC classification for products (see MDA Module specification for 
details of formulas). 

20 Compute and analyze correlation between the demand for dfTerent product groups. 

Compute, display (tables and graphs), and analyze new products and model change-over profiles. 

Compute, display (tables and graphs), and analyze inventory profile per customer. 

Compute, display (tables and graphs), and analyze trade inventory by comparing POS and shipment data 

25 Market Data 

This operation involves the operations discussed below. 

Display (tables and graphs) Market Data 140 (volume, value, market share) by product group, region, or customer 
group (Nielsen, EIA, etc.). 

30 Conpute. display (tables and graphs) and analyze Market Data 140 statistics for different levels of aggregation: 
This year vs. last year. Trend, Actual statistics vs. budget assumption, and Seasonality. 
Pareto analysis of competitors (value and volume). 
Create price information: list of competitor products per price range 

as Bottom-Up Demand Forecasting 

The objective of the Bottom-up forecasting is to develop a customer specific sales forecast based on historical ship- 
ment to the customer, POS information at the customer location, and the customer's own forecast regarding its future 
orders. 

40 

Acquire. Display, Edit data 

Data Acquisition consists of selecting a data Domain (specific pairs of customer and product), and choosing the 
type of data to be displayed: shipment or POS (when available). 
45 Forecasts generated in the Bottom-up forecasting frame can be saved back to the DSS Database 12 or alterna- 
tively saved as scenaria 

Bottom-up (BU) Forecast generation 

so This operation involves the operations discussed below. 

Input and maintain customer orders: Forward orders, and Orientation orders. 
Choose model for statistical forecast 

Generate and display (tables and graphs) statistical forecast at different level of aggregation (POS or Shipment 
data): Customer group, Individual customers for ail products, and Individual customers for each product 
59 Support integration in BU forecast of expert knowledge for optimtstic^essimistic forecast 
Formulate disaggregation logic of BU Forecast at customer level onto products. 
Incorporate impact of future promotions for customer specific promotions. 
Conpute. display and edit seasonality factors. 
Review actual seasonality against planned and "company* seasonality. 
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Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or 
Shipment data): Customer group. Individual customers for aO products, and Individual customers for each product 

Compute and display (tables and graphs) sales and forecast statistics: Moving average. Year to date/balance of 
year. This year v& last year, and Actual/forecast vs. Budget 
5 Support comparison of POS and Shipment data for analysis of change in trade inventory profile. 

Invoke forecast accuracy estimation routine. 

Top-Down Forecasting 

10 The objective of the Top-down forecasting is to develop a product centric sales forecast based on historical demand 
data and industry analysis that accounts for market-wide trends. 

Acquire; Display, Edit data. 

15 The data Acquisition consists of selecting a data Domain (specific pairs of customer and product), and choosing 
the type of data to be displayed: shipment or POS (when available). 

Forecasts generated in the Top-down forecasting frame can be saved back to the DSS Database 1 2 or alternatively 
saved as a scenario. 

20 Top-down (TD) Forecast generation 

This operation involves the operations discussed below. 
Choose model for statistical forecast 

Generate and display (tables and graphs) statistical forecast at different level of aggregation (POS and Shipment 
25 data): market level, product group level, and product One level. 

Incorporate industry trend analysis developed in Demand Characterization in TD forecast 
Formulate disaggregation logic of TD Forecast at product level onto customers. 
Incorporate impact of future product specific promotions. 

Compute and display (tables and graphs) sales and forecast statistics: Moving average. Year to date/balance of 
30 year, This year vs. last year, and Actual/forecast vs. budget 
Compute, cfisplay and edit seasonality factors. 
Review actual seasonality against planned and "company" seasonality. 

Disaggregate yearly forecasts onto each period using seasonality factors at different levels of aggregation (POS or 
Shipment data): market level, product group level, and product fine level. 
38 Support forecasting of model change over, and introduction of new products. 
Invoke forecast accuracy estimation routine. 

Sales Promotion Analysis 

40 Theobjectiveof Sales PromotidrTArial^ 

the promotion calendar, estimating the impact of future promotions and assessing the effect on sales of past promo- 
tional activities. The promotion calendar is a table in which the various characteristics of past and future promotions are 
recorded. The knowledge and insights gained in sales promotion analysis are used in adjusting bottom-up and top- 
down sales forecasts. 

4$ The functional features associated with Sales Promotion Analysis are given below. 

Maintain Promotion Calendar and add new promotions: Time period of promotion. 

Type of promotion (defined by who initiates the promotion: firm, retailer, competitor), and Class of promotion 
(defined by the nature of the promotional activity). 

Intensity of promotion: Search and sort promotion calendar, and Analyze Past Promotions. 
50 Display sales data along with information of promotions under consideration. 
Establish profile for the impact of the sales promotions. 
Analyze promotions) effect through regression or time series models. 

Partition sales: Display actual sales attributable to normal sales, seasonal effect and promotion effect 
Plan Future Promotions. 
55 Add promotion in promotion calendar - specify type; class, intensity and time period. 
Estimate impact of future promotion based on the impact of similar past promotions. 
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Forecast Performance Evaluation 

The objective of For ecast Performance Evaluation is to assess tfi e accuracy of past sal es forecasts. Forecast accu- 
racy is an important measure tor several purposes: 
5 It helps the user to refine the forecasting process by providing feedback on the ability of different models and 
approaches to forecast future demand; 

It provides a measure of demand variability that is used to assess necessary safety stock; and 
It guides attention to those products and customers for which demand is difficult to forecast and that require special 
attention 

to Two types of forecast performance evaluations are considered: forecast accuracy of one particular version of the 
forecast and average accuracy of n periods ahead forecast 

The first forecast performance type provides point estim a tions of forecast accuracy, while the second one is an 
average estimation of the accuracy as a function of the number of period in advance a forecast is produced 
The functional features associated with Forecast Performance Evaluation are given below, 
is Select data domain. 

Compute and display Forecast errors for: Bottom up forecast Top down forecast and Sales plan (invoked from 
PSI). 

Maintain Accuracy Matrix for each type of forecast (table of the forecast accuracy n periods ahead). 
Generate exception report based on level of forecast error for different level of aggregation. 

so 

Equipment Repair Supply Chain 

In the context ot the Equipment Repair Supply Chain the term "Requirements Management" is used in place of 
"Demand Management" to indicate that equipment generates "repair requirements" when it breaks down. 
25 Requirements Management is the process of estimating the future requirements of reparable items at the equip- 
ment location. This process can be divided into two main sub-processes: 

Evaluation of the raw requirements for each equipment; and 

Estimation of the consolidated requirements at the level of each location (several pieces of equipment can be 
so located at the same location). 

These two approaches can be used to estimate future consolidated requirements. 

Bottom-up method: This approach uses a combination of two models: (1) the first model estimates the raw require* 
merits of an equipment by modeling its failure rate as a function of the equipment's activity (or usage) and (2) the sec- 
35 ond model estimates the consolidated requirement based on the raw requirements and the consolidation policy. 

Top down method: This approach is based on the projection of historical data for the consolidated demand. To sup- 
port the two different approaches the functional requirements detailed below have been defined. 

Activity tracking for raw requirements estimation 

4fr— — — 

This involves the operations discussed below. 
Select and Display Activity Data. 

Maintain Future Activity Data: Planned Equipment upgrade/maintenance schedules; and Planned Equipment 
usage schedules. 

45 . -jn . 

Analyze Past Activities 

Review activities: Display historical raw requirements data along with activity data. 
Assess impact of past activities using regression or time series models, 
so Per type of equipment 
Per type of activity. 

Relate future raw requirements to planned activities. 

Use models of past activities to project the effect of future activities. 

M Consolidated requirements estimation based on raw requirements (bottom-up) 

This operation involves the operations discussed belo*. 
Select and Display Consolidated Requirement data. 

Formulate, and refine consolidation policy (see SFP Module for explanation regarding consolidation policies). 
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Evaluate different consolidation policies based on past raw requirements. 
Estimate future consolidated requirements based on chosen policy. 

Consolidated requirements estimation based on historical data (top-down) 

5 

This involves the operations discussed below. 
Select and Display Consolidated Requirement data. 

Choose model for statistical forecast of future usage per repair item/repair item group 
Kalman Filter based algorithm for requirements estimation (considered appropriate for forecasting equipment fafl- 
10 ures). 

Other statistical forecasting techniques. 

Generate and display (tables and graphs) statistical forecast at different level of aggregation: Repair Hern group. 
Individual Repair item for all equipment and Individual Repair item for each equipment 

Compute and display statistics (tables and graphs) for actual and estimated consolidated requirements: Moving 
15 average. Year to date/balance of year. This year vs. last year, and Actual/forecast vs. Budget 

Develop disaggregation logic of consolidated requirements estimation Forecast at repair item group onto individual 
Repair item. Users can override algorithm based estimates. Requirements reconciliation and requirements plan gener- 
ation 

This operation involves the operations discussed below. 
20 Compare and analyze top-down and bottom-up requirements numerically and visually. 
Reconcile the top-down and bottom-up requirements to generate the requirements plan. 
Use weighted average models. 
Incorporate user's input and override. 

25 Requirements estimation performance evaluation 

Store top-down, bottom- up and reconciled requirements estimates. 

Compute and cfispiay Estimation errors fa: Bottom up requirement estimation. Top down requirement estimation, 
and Reconciled requirement estimation. 
so Maintain Accuracy Matrix for each type of requirement estimation (table of the accuracy n periods ahead). 
Generate exception report based on level of estimation accuracy for different level of aggregation. 

Production-Sales-Inventory Planning (Requirements-Supply Reconciliation) Frame 

35 The PSI Planning Frame 160 supports the PSI planning decision process described here. 

Module and Data Space Association 

Figure 15 shows the participating modules and the associated data spaces for this frame. 

40 The PSI Planning Frame r T60~requires the partidr^tion of three moo\jles: the S^ 

(SFP) Module 132. the Aggregate Production Planning (APP) Module 162. and the Finished Goods Inventory Manage- 
ment (FGIM) Module 164. The PSI Planning Frame 160 as a whole involves S. I. and D data spaces with iterative data 
transformations among each pair. 

45 - Process Flow — — - 

The process flow diagram for the PSI Planning Frame 1 60 is shown in figure 1 6. The PSI Planning Frame 1 60 sup- 
ports the following functional requirements identified for the PSI planning decision process: 

so Forecast Reconciliation 

The Demand Management Frame 130 supplies the Forecast Data 146 (bottom-up and top-down forecasts). The 
PSI Reconciliation Activity 170 in concert with the SFP Module 132 revises the top-down forecasts and reconciles the 
bottom-up and top-down forecasts. This is an iterative process which is shown as the "S" loop (in the top right quadrant 
55 ) in the process flow diagram. H any changes to the bottom-up forecasts are warranted, the PSI Planning Frame 160 
interacts with the Demand Management Frame 130 to make the necessary changes. 
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Inventory Planning 

The PSI Reconciliation activity 1 70 in concert with the PGIM Module 1 64 determines the inventory requirements in 
an iterative fashion. This is shown as the "I" loop (in the top left quadrant) in the process flow diagram The inventory 
5 requirements are written to Inventory Data 182. The FGIM Module 164 as part of the PSI Planning Frame 160 also for- 
mulates the finished goods inventory policies; the policy parameters are written to Inventory Parameters 1 72. 

Supply Requirement Planning 

io The PSI Reconciliation Activity 1 70 in concert with the APP Module 1 60 determines the production requirements 
that are consistent with the sales plan and the inventory requirements in an iterative fashion. This is shown as the "P" 
loop Cm the bottom right quadrant) in the process flow diagram. The production requirements are written to Production 
Requirements Data 174. The APP Module 160 as part of the PSI Planning Frame 160 also checks aggregate produc- 
tion capacity and key component availability using Production Capacity Data 160 and Inventory Data 182 (component 

is availability). 

Produdion-Sales-lnventory-Plan Coordination 

The PSI Reconciliation Activity 1 70 interacts with the APP Module 1 60. the SFP Module 1 32. and the FGIM Module 
20 164 to coordinate the integrated production-sales-inventory planning. This involves the evaluation of various plan 
options, enacting the consistency of the constituent plans and resolving conflicts, if needed. 

Data Flow 

25 The data flow diagram for the PSI Planning Frame 160 is shown in figure 1 7. The PSI Planning Frame 160 gener- 
ates the Production-Sales-lnventory Plan report 190 fisted earlier. 

The Production-Sales-lnventory (PSI) Planning is a process to reconcile demand and supply requirements in a 
supply chain. In the manufacturing environment, the PSI Planning Frame 160 helps to reconcile production, sales and 
inventory requirement discrepancies. In the repair environment the requirements-supply reconciliation helps to recon- 

30 die requirements and supply. 

Manufacturing Supply Chain 

The PSI Planning Frame 160 supports the process that develops an integrated production-sales-inventory plan for 
35 a selected product group. The objective is to ensure that the resulting PSI plan 190 meets customer requirements and 
satisfies supply capability constraints and the inventory objective of the company. The current PSI plan 1 90 is displayed 
together with a temporary PSI plan 190. The temporary PSI plan 190 can be imported from various data sources 
(including data series from Scenarios 78). The user can then analyze and modify the temporary PSI plan 190 with easy 
reference to the current PSI plan 190. The user can replace the current PSI plan 190 by the temporary one once the 
40 tatter has been improved to satisfaction. _ 

The PSI planning process requires the support of three modules: the Sales Forecasting and Planning (SFP) Mod- 
ule 132. the Aggregate Production Planning (APP) Module 162 and the Finished Goods Inventory Management (FGIM) 
Module 164. 

45- Forecast Reconciliation : TL. — 

The Demand Management Frame 130 supplies the Forecast Data 1 46 (bottom-up and top-down forecasts) and an 
indication of the methods used to generate them. The user can use the same methods to generate new forecasts and/or 
compare the forecasts generated by different methods. The user analyzes and reconciles these forecasts to generate 
so an appropriate set of sales requirements. The PSI Recordation 1 70. with the support of the SFP Module 1 32. revises 
forecasts and reconciles top-down and bottom-up forecasts. 

Revise forecasts 

55 The forecast revision process acquires, displays, analyzes and edits the bottom-tp or top-down forecast The user 
first acquires forecasts generated using different methods from the Demand Management Frame 130. After analyzing 
these forecasts and comparing the results, the user then selects the most appropriate one to be used. The following 
features are identified tor this process: Acquire and display forecasts; Check forecast errors; Compute and display 
related statistics of sales; and Select forecasts. Individual descriptions of these four features are as follows. 
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Acquire and display forecasts. 

This feature consists of the following four steps: 

Choose product group: The user specifies the product group of interest 
5 Choose aggregation level: The user specifies the aggregation level (&g. month, year) for data display. 

Import forecasts: The DSS 1 0 acquires the bottom-up and top-down forecasts generated in Demand Management 
Frame 130 for the selected product group from the DSS Database 12. 

Display forecasts: The DSS 10 aggregates/disaggregates as appropriate the forecasts to display at the chosen 
aggregation level. 

10 

Check forecast errors 

The forecast error checking feature supported by the SFP Module 132 computes and displays various n -period- 
ahead historical errors of the bottom-up and top-down forecast 

15 

Compute and display related statistics of sales 

The sales statistics computation feature supported by the SFP Module 132 computes: mean and variance over a 
selected time interval, moving average, trend, and/or seasonality factors of any chosen sales One and display result in 
20 several forms (graphical, tabular or both). 

The forecast selection feature interacts with the Demand Management Frame 130 to check bottom-up forecasts 
25 from various sources and the result of various top-down forecast methods (e.g. moving average, regression, combina- 
tions, etc.) The user then chooses the most appropriate set of bottom-up and top-down forecasts based on their accu- 
racy, statistics and consistence with each other. 

Reconcile top-down and bottom-up forecasts 

30 

The process of top-down and bottom-up reconciliation checks the discrepancy between the two forecasts and if 
necessary, resolves the conflicts between the two forecasts to generate a more desirable sales forecast The following 
features are provided to support this process: Compute the difference between top-down and bottom-up forecasts; 
Generate weighted average of top-down and bottom-up forecasts; and Manually overwrite temporary sales (S*) line 
35 (see the screens discussed later herein). Individual descriptions of these three features are as follows. 

Compute the difference between top-down and bottom-up forecasts. 

The difference between top-down and bottom-up forecasts is computed and displayed to show the discrepancy 
between the two forecasts. 

Generate weighted average of top-down and bottom-up forecasts. 

40 The conflicts between the top-down and bottom-up forecasts can be resolved by using a weighted average of them 
to generate a new temporary sales forecast in the S' line. 
Manually overwrite temporary sales (S*) line 

The user manually overwrites the forecast on the S* fine to adjust the sales forecast to reflect various considerations 
of influential factors. For example, adjust sales forecasts to account for unrecorded or anticipated upcoming market 
45 changes: "~ * 

Inventory Planning 

The process of Inventory Planning supported by the FGIM Module 164 and the Demand Management Frame 130 
so determines the finish goods inventory requirements In inventory planning, the user first selects a product group. To help 
the user to select an appropriate inventory policy, the DSS 10 computes and displays various sales measures which 
characterize the sales pattern of the chosen product group. For example, a Min-Max policy might be appropriate for a 
product group facing steady demand. The OSS 10 then, based on the inventory policy selected by the user and the 
managerial sales and service targets, determines the policy parameters and inventory level requirements. The user can 
55 then modify the policy parameters and inventory level requirements to satisfy various managerial requirements and pro- 
duction resources limitations. The following two features are identified for this functional requirement Formulate fin- 
ished goods inventory policies; and Determine finished goods inventory requirements. 



23 



EP0770967A2 



Formulate finished goods inventory poOdes 

The formulation of finished goods inventory policies involves the selection of inventory policies for chosen product 
groups and specifying the corresponding poOcy parameters, ft is broten down into the following features: Choose inven- 
toy poOdes tor product groups; Choose policy parameters; and Compute estimated inventory statistics. 

Individual descriptions of these three features are as follows. 

Choose inventory policies for product groups 

In this feature, the user select inventory policies for product groups based on the patterns of sales the product 
groups are facing. It involves the following three steps: Choose product group: The user specifies the product group(s) 
of interest; Acquire the following sales measures from the Demand Management Frame 1 30: Usage rate - fast medium 
or slow moving, Lumpiness • sparseness of significant demands, and Volatility - coefficient of variation; and Select 
inventory policy: The user chooses among the following an inventory policy for the chosen product group(s) based on 
the sales information acquired. 

For single product group with non-lumpy demands: User-specified base-stock poGcy. Periodic review cost optimi- 
zation policy, and Period review model with service level constraints. 

For related multiple product groups (e.g. groups sharing the same production resources.) with non-lumpy 
demands: Leveled Policy, Synchronized Policy, and Optimal Policy. 

For single product group with lumpy demand: Maximum n-Period Coverage Policy. 

Choose policy parameters 

The FGIM Module 164 based on the service level constraints and managerial objective (e.g. minimize inventory 
carrying cost with a stock out probability of at most 5%) determines the policy parameters to be used for the inventory 
poGcy chosen by the user. The user can then observe the results of the estimated inventory statistics and adjust the 
policy parameters as appropriata 

Compute estimated inventory statistics 

The estimated inventory statistics calculation feature supported by the FGIM Module 164 computes and displays 
the following inventory related measurements: average inventory level (as weeks of sales); expected stock-out proba- 
bility; service level (fill rate); inventory carrying cost; and total cost (including production, inventory holding, stock out 
penalty and transportation costs) for the chosen inventory policy and poficy parameters. 

Determine finished goods inventory requirements 

The FGIM Module 164 based on the inventory policy and policy parameters determines the finished goods inven- 
tory requirements for the product groups. The user can then modifies the inventory level requirements as appropriate. 
The follcwing features "are td^ified foTdeti^ining the finished goods inventory requirements: Compute and display 
inventory level at chosen aggregation level; Manually override inventory levels; and Compute and display inventory level 
at chosen aggregation level. 

The PSI Planning Frame 160 supported by the FGIM Module 164 computes the inventory levels based on the cho- 
sen inventory policies and parameters. The result will be displayed in the temporary inventory (I*) line. If the computation 
is done at a lower aggregation level than the chosen one for display, the corresponding appropriate aggregation will be — 
done before display. 

Manually override inventory levels 

The user can manually overwrite inventory levels to reflect various managerial concerns For example, the unavail- 
ability of production resources at certain periods requires the decrease in corresponding inventory labels or the sug- 
gested inventory level exceeds the given management target 

Supply Requirement Planning 

The supply requirement planning feature supported by the APP Module 160 help determines the production 
requirements that are consistent with the sales plan and the inventory requirements. It also checks the feasibility of the 
production requirements with respect to production capacity and key component avaOabiGty. In case of infeasfeSHy, the 
feature wfll provide information about the cause of corresponding infeasibility to the user. The user can then modifies 
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sales requirements, increases available resources (production capacity or key component availability) and/a prioritizes 
the sales requirements and restricts attention to satisfy a reduced set of high priority sates requirements only in order 
to achieve feasibility. 

s Determine production requirements to sustain sales 

The process of determining production requirements to sustain sales consists of the following two features: Gener- 
ate production requirements; and Manually overwrite the production requirements* Individual descriptions of these two 
features are as follows. 

to 

Generate production requirements 

The production requirements generation feature supported by the APP Module 160 determines the production 
requirements based on sales and inventory requirements. There inventory requirements may take two different forms: 
is Inventory levels, a Safety stocks. 

In case of inventory level requirements, the production requirements are generated using the inventory balance for- 
mula discussed herein. 

(n case of safety stock inventory requirements, the user can choose one of the following objectives to determine the 
production requirements: Minimize the maximum production capacity utilization; Minimize the maximum inventory level; 
20 Minimize the total inventory level; and Minimize the total inventory cost (inventory holding and backlog penalty costs 
required). 

The production requirements generated are displayed in the temporary production (P) fine. If result of sanity check 
is at a lower aggregation level than the one chosen tor display, aggregation will be done before display. 

25 Manually overwrite the production requirements 

The production requirements are modified to reflect various considerations. For example, insufficient production 
resources during certain periods. 

so Check aggregate production capacity & key component availability 

In the process of checking the feasfcilrty of sales, inventory and production requirements against the availability of 
production capacity and key components, the following features are identified: Define key components: Check sanity of 
a given set of sales requirements (in S* One) and safety stock constraints; Check feasibility of production requirements 
35 (in F line); and Update and display production capacity load and key component availability. Individual descriptions of 
these four features are as follows. 

Define key components 

40 Each user defines a list of key components, which is recorded and can be modified whenever necessary. The list 
of all components which are sorted according to their availabOityAisage ratio is displayed to help the user to define or 
modify the list of key components. 

Check sanity of a given set of sales requirements (in S' One) and safety stock (in r line) constraints 

45 — " 

The process of sanity check utilizes the capacity checking model in the APP Module 160 to help determine the pro- 
duction requirements for the given set of the sales requirements and safety stock constraints. Furthermore, the user can 
scope the capacity checking model appropriately through modification of: Locations), Products or product groups. 
Time horizon, Production fines, and Key components. 
so ff the results of the capacity model are inf easibie. critical under-capacitated production resources and key compo- 
nents are suggested to the user for further modifications. 

Check feasibility of production requirements (in P' line) 

55 This process checks sanity of a given set of production requirements against the production capacity and key com- 
ponent availability. This is also supported by the capacity checking model in the APP Module 160. Similar to the previ- 
ous sanity check described above, the user chooses the appropriate scope of the capacity checking model and if it 
turns out to be inf easibie, critical under-capacitated production resources and key components are suggested to the 
user for further modification. 
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Update and di^jlay production capacity load and key component availability 

After a few iterations of the sanity checks and capacity requirement adjustment the user can reach a feasible set 
of production requirements. The remaining available production capacity and key components are updated and can be 
displayed if requested. The user can then accept or reject new production requirements based on the availability of pro- 
duction capacity and key components. 

Product! on-Sales-lnverrtory Plan Coordination 

The coordination of the production-saiesHnventory plan ensures consistency among the production, sales and 
inventory plans and helps determine a feasible and appropriate PSI plan 190. 

Check and ensure consistency in PSI plan 

The user can utffize this feature in either: the independent mode or the consistent mode. 

In the former mode, the user can edit the production, sales and inventory requirements separately by disregarding 
any consistency requirement In the latter mode, the OSS 10 always ensures the consistency of the production, sales 
and inventory requirements. In the consistent mode, the following features are identified: Modify the plan according to 
the user defined sequence: Maintain the consistency in other lines due to the change of one line; Update the production 
(P). sales (S) and inventory (I) lines (see display figures discussed herein) by their corresponding temporary Ones; 
Maintain consistency at different aggregation level (tor either the consistent or independent modes only). Individual 
descriptions of these features are as fbOowa 

Modify the plan according to the user defined sequence 

When the user first switches to the consistent mode, two of the temporary production, sales and inventory Ones 
have to be selected to generate the third line using the inventory balance formula discussed herein. 

Maintain the consistency in other lines due to the change of one One 

Whenever a temporary production, sales or inventory One is overwritten, it will be modified together with one of the 
remaining two fines (preselected and can be re-selected anytime by the user) to maintain consistency. 

Update the production (P). sales (S) and inventory (I) Ones by their corresponding temporary lines 

The user can replace the set of P, S and I display lines (see dsplay discussion herein) by a set of consistent P\ S* 
and r Ones. The P. S and I lines can always be saved as a scenario. Only user with the appropriate system privilege can 
save the P, S and I lines to the DSS Database 12 permanently. 

Iteintainc^ level ~~~~~~~~ 

The DSS 10 can display data at any resolution higher than the primary data resolution level. Whenever display at 
a higher resolution is modified, disaggregation will be done to maintain consistency. The DSS 10 computes a set of 
default disaggregation logic based on existing lowest resolution data. The user can overwrite the disaggregation logic 
whenever appropriate. — — — — 

Evaluate PSI plan options 

The PSI plan options evaluation feature computes and displays the performance metrics for various versions of the 
PSI plan 190 for the user to compare and choose a desirable one. The following two features are identified to support 
this feature: Compute relevant performance metrics: and Compare different plans. Individual descriptions of these two 
features are as follows. 

Compute relevant performance metrics 

The following performance metrics are computed using the routines specified in the SFP 132, FGIM 164 and APP 
Module 160 to assist the user to select a more desirable version of the PSI plan 190: Total and breakdown of costs. 
Average inventory level. Average expected stock-outs. Expected Throughput Time, and Expected Service level. 
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Compare different plans 

Different PSI plans 1 90 over the same or different time periods together with their corresponding performance met- 
rics are displayed side by side tor comparison purposes. 

Repair Environment 

In the Repair Environment the term "Requirements-Supply Reconciliation" is used in place of Production- Sales- 
Inventory planning. This reflects the fact that there is no production nor sales in a repair environment but 'repeat require* 
merits" and "repair supply" in the form of repair workstation capacity and component availability. "Requirements-Supply 
Reconciliation* Planning is a reconciliation process that develops an integrated and feasible plan. 

The Requirements-Supply Reconciliation comprises of two main processes: Estimation of the aggregate repair 
requirements based on the inventory position of serviceable parts at the repair location and the target level for this 
inventory; and Feasfr&ty assessment for the aggregate repair requirements under resource capacity (skills and work- 
stations) and component availability constraints. To support these processes the following functional requirements have 
been defined. 

Evaluate and propose Consolidated Serviceable Inventory (CSI) Levels based on past usage and future usage 
requirements. 

The tofl owing operations are performed: Refine variability and lumpiness estimates of usage; Refine repair lead 
time estimates; and Propose target CSI levels. 

Determine Aggregate Repair Requirements 

This includes using target CSI levels, and current inventory positions to determine aggregate repair requirements. 

Generate Aggregate Repair Plan 

This includes the following: Verify repair resource capacities to satisfy aggregate repair requirements based on; 
repair personnel sWfl sets; workstations features; Verify key component availability to satisfy aggregate repair require- 
ments; and Generate aggregate repair plan under capacity and component constraints. 

Supply Management 

The Supply Management Frame 200 supports the Supply Management decision process. 
Module and Data Space Association 

Figure 18 shows the participating modules and the associated data spaces tor this Frame 200. 
"Process Row 

The process flow diagram for the supply planning frame 200 is shown in figure 1 9. The Supply Management Frame 
200 supports the following functional requirements identified for the Supply Management decision process: 

Aggregate Production Planning . zi 

The APP Module 160 works closely with the FGIM Module 164 and uses Inventory Data 182 and the Production 
Capacity Data 180 to evaluate production and inventory trade-offs. The APP Module 160 also uses the Production 
Requirements Data 174 from the PSI Planning Frame 160 to generate aggregate production plans. These are written 
to the Aggregate Production Plan Data 202. 

Dynamic Replarming 

The aggregate production plan is often modified by the APP Module 160 to reflect either changing production 
requirements provided by the PSI Planning Frame 160 through the Production Requirements Data 174 a changing 
component availability from the Material Planning activity 210 through Material Delivery Schedule 212. 
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Capacity Planning 

The APP Module 1 60 utilizes long-term Production Capacity Data 180 from the Product Planning activity 214, the 
production parameters such as process times from Production Matrix 21 6. and the planning biH-of-material for the prod- 
s uct from Planning BOM 218 to determine the production capacity requirements. In so doing, the APP Module 160 may 
evaluate a number of production capacity options such as various production line structures and allocation of 
resources. The capacity plan is written to Production Capacity Data 1 80. 

Component Procurement Policy Development 

The Component Procurement Policy Development (CPPD) Module 230 reviews the long-term component require- 
ments in Component Requirement Data 232 and other relevant component supply information to formulate component 
procurement policies. The component procurement policy parameters are then written to Component Supply Contract 
234. 

15 

Data Flow 

The data flow diagrams for the Supply Management Frame 200 are shown in figure 20 and figure 21 . The Supply 
Management Frame 200 generates the core report previously discussed, namely, the Master Production Plan 240 and 
so the Production Capacity Plan 242. 

Vendor Managed Replenishment Frame 

The Vendor Managed Replenishment (VMR) Frame 250 supports the VMR decision process. 

25 

Module and Data Space Association 

The Data Space associations for Frame 250 are illustrated in figure 22. 
30 Process Row 

The process flow diagram for the VMR Frame 250 is shown in figure 23. The VMR Frame 250 supports the func- 
tional requirements identified for the VMR decision process: 

35 VMR Strategic Planning. 

The VMR Strategic Planning activity 252 in concert with the MDA Module 134 and the FGIM Module 164 considers 
the financial and business requirements supplied by the customers, dstrtoution infrastructure, POS history and the 
transportation factors in the Supply Chain Network data table 260 to evaluate various service contract options. The 

4Q~~ VMR cxirTtf^p^ ~~~~~~ 

Replenishment Planning 

The Replenishment Planning activity 270 worWng with the MDA 134 and the SFP Module 132 reviews the sell- 
45 through information and provHes input to the FGIM Module 164 to generate the corres pondin g replenishment require^ 
merits. These requirements are refined according to the VMR Contract 262. Based on these inventory requirements, 
the VMR Contract 262 and the order fulfillment activity, the replenishment schedule is generated and written to VMR 
Data 27* 

so Data Flow 

The data flow diagram for the VMR Frame 250 is shown in figure 24. The VMR Frame 250 generates the Replen- 
ishment Schedule report 280 listed earlier. 

VMR, also referred to as direct replenishment is a growing agile logistics partnership agreement where the vendor 
55 takes on the responsfoifity of managing the inventory at the customer sites for the products it supplies, i.e., monitoring, 
planning, and directly replenishing the inventory in the customer's distribution network. In other words, under a VMR 
arrangement it is the vendor who determines when stocks are to be replenished and in what quantities, rather than 
responding passively to orders placed by the retailer. This arrangement is usually typified by a contract which specifies 
the finandal terms, inventory constraints, and performance targets such as service measures. VMR is almost invariably 
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based on the availability of direct access to point-of-sale data and the customer's inventory positions. Such an arrange- 
ment can be mutually advantageous to the customer and the supplier. 

On the other hand, VMR requires the integration of inventory and transportation planning processes of the supplier 
and the customer. Although much has been written in the genera) literature about VMR as a concept (eg., Wat- Mart's 
5 relationships with its suppliers) there are few known quantitative models, if any, to support VM R. Existing VM R systems 
are transaction oriented and provide little or no decision support capabilities. 

The VMR Frame 250 consists of a set of decision support tools that can be used in the development of VMR pro- 
grams. The features offered by the VMR Frame 250 support the decision making processes in the VMR programs at 
both strategic and operational levels. More specifically, at the strategic level, the user can invoke the features provided 
to by the Frame 250 to study of the feasMrty of VMR programs; evaluate the terms of VMR contracts; and periodically 
review the overall performance of the VMR program. 

At the operational level, the user can invoke the Frame features to develop sell-through forecasts; obtain suggested 
replenishment quantities; revise replenishment quantities; and monitor sales and other VMR related statistics. 

In this section, we win provide the functional specification tor the VMR Frame 250. The entire Frame 250 can be 
is partitioned into three main parts: basic and VMR specific data maintenance, strategic planning and replenishment plan- 
ning. It supports the following two functional requirements: VMR Strategic Planning: Evaluate financial and logistical 
tradeoffs in a VMR contract and Comparative analysis of various service contract options; and Replenishment Plan- 
ning: Review sell-through and determine inventory requirements at retailer's location, and Formulate the replenishment 
plan. 

20 The main decision modules to support the VMR Frame 250 include MOA 134, SFP 132. VMR and APP 160. We 
wiO discuss the functional specifications that are applicable to the manufacturing environment 

Data Maintenance 

25 To support general functionality of the VMR Frame 250, the system should maintain two types of data: the Basic 
Structural Data and the Replenishment Data. In the following two sub-sections we discuss the details of these two sets 
of data. 

Basic Structural Data 

30 

These include the essential data elements required to describe the basic characteristics of the products, distribu- 
tion network, etc. This set of data are relatively stable and require onJy infrequent updates (eg., at the time when the 
VMR program is being initialized, or when new models are being added to the program). These include: 

38 Distribution Network: Define the customer as well as the vendor's product distribution networks that are relevant to 
the VMR program, it identifies which product is being distrfcuted from which vendor warehouse and which cus- 
tomer Distribution Center (or store) are assigned to each warehouse. 

Distribution Center (DC) Profile: Define the main attributes of a customer DC or a vendor warehouse inducting its 
location (city and state) information. 

40 Lead-times: Define the lead-time for product distrit^n between a given pair of labors the corresponding 

transportation modes. 

Transportation Costs: Define the transportation costs tor product distribution for given transportation modes. 
Product Prof Be: Define the main attributes of the products participating in the VMR program including their IDs and 
physical characteristics. It also specifies whether a product is currently in the VMR program. 

45 Product Replacem^Relationship:_Define the ^ 

replaced). This provides the basic information to establish a continuous demand stream tor a pair of closely related 
products. 

Replenishment Data 

so 

Replenishment data are more dynamic, and record the details about the replenishment activities as well as the 
characteristics of the VMR program itself. These include: 

Product and DC Watch List: A set of products and DCs that are defined by the user to be monitored by the system 
55 so that any special movements or activities can be detected and reported. 

Seasonality Factors: The set of factors calculated by the system or provided by the user to characterize the basic 
seasonal fluctuation patterns in the sales activities. 

Replenishment Orders (Receipts, In-transit, Incomplete, etc.): The detailed order status information that is 
recorded to capture the replenishment activities induded in the program. 
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Maximum and Average Inventory Levels: The targeted maximum and average inventory levels specified in the VMR 
contract They can be used to monitor the current performance of the VMR program. 
Service Levels: The targeted customer service levels specified in the VMR contract 

Delivery Frequency: The delivery frequency is defined by the user or the system and it specifies the frequency at 
which the products are replenished for a particular customer DC. 

Promotion Calendar: The calendar captures the relevant promotion activities This information is then used to 
ensure that a sufficient additional amount is included in the regular replenishment quantity. 

Strategic Planning 

Strategic planning features mainly support VMR decisions during the initial program setup; important during VMR 
contract negotiation stages. They are also useful to provide critical operating parameters, e.g., replenishment frequen- 
cies. Finally, they are also needed to conduct long-term performance reviews. Therefore, the functions provided at the 
strategic level are addressing the issues which are of long-term irrportance, even though these decisions are not made 
so frequently. 

VMR Contact Setup 

During the initial stage of potential engagement in a VMR program, the conditions in the VMR contract are pro- 
posed, stucfied and negotiated. Under such circumstances, the user needs to evaluate the costs and benefits of many 
different program options. When the terms are conflicting, tradeoffs have to be made. In addition, one also has to 
choose a set of operating parameters and procedures which optimize total cost measures while satisfying given con- 
straints. The features provided below are to support these decision making problems. 

For a product/product group, a customer DC. and a delivery frequency defined by the user, the system will provide 
the computed relationship between expected service level and maximum (average) inventory level. Such a relationship 
win also be useful for the user to evaluate what-if Scenarios and can be used in other features in this Frame (e.g.. the 
Replenishment Planning below). 

Compute and display expected service level for the maximum inventory requirement defined by the user. 

Estimate and display the proper inventory level for a given service level defined by the user. 

When evaluating the optimal VMR operating parameters or conditions in the contract the system can help the user 
to either check the compatibility of a set of constraints including service level, inventory level and delivery frequency, or 
select an optimal set of these parameters after the evaluation of afl feasible combinations. 

To use this feature, the user first needs to choose the product/product group and the DC of interest 

For a given replenishment scenario (a given set of delivery frequency, target inventory level and customer service 
level), the system will estimate the total cost including customer DC inventory carrying cost transportation cost and 
manufacturing plant inventory carrying cost. 

Different replenishment Scenarios can be generated based on different values of delivery frequency, target average 
inventory level and target customer service level. In order to compare these different options without using total pro- 
jected costs like the one suggested in the feature above, the system will compute key statistics such as expected inven- 
tory levels at customer DCs and manufacturing plants: By comparing these statisticsra better replenishment scenario 
can be identified. 

Contract Parameter Monitoring and VMR Program Review 

After a VMR program has been setup and the execution started, rt requires roretart^ 

parameters and performance measures. If there are substantial changes, it is critical to report them back to the users. 
This is because the optimal operating parameters in the VMR program set at the strategic level are obtained under cer- 
tain assumptions about these key indicators. In addition, periodically, the management will be interested in the actual 
effectiveness of the VMR program. To support such program reviews, the system will record and generate management 
reports regarding the actual performance of the VMR program compared to the inventory and customer service level 
targets set in the VMR contract 

Periodically (which can be defined by the user), the system win compute the mean and standard deviation of the 
sell- through for a given product of a given customer DC. Trie resulting numbers can then be compared to the historical 
norm defined by the user, the quantitative modeling assumptions, or recorded by the system. H the mean and standard 
deviation are outside of the defined range, then the user has to be informed through a product sales exception report 
or other similar reports. The user wfll be asked to define the following: Frequency of such evaluation; Historical norm of 
the mean and standard deviation; and The ranges of the mean and standard deviation. 

One of the key objectives of any VMR program is to reduce the total inventory levels at different parts of the supply 
chain. The system will compute and record average inventory levels and compare it to maximum and average inventory 
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targets The results can then be reported to the user as requested 

When the inventory level of a given productyproduct group at a customer DC is much higher than needed, part of 
the inventory should be considered as excess. The system win report the Ost of products whose inventories are in 
excess. These products then wfll be off the replenishment product fist until the inventory levels return to a normal range. 
During these periods, the production and many other logistics operations planning will have to be notified about the 
reduction in planned quantities^ 

Replenishment Planning 

This is to support more operational decision problems on a regular basis after the VMR program has started its exe- 
cution. During this stage, the main concerns of the user will be shifted to those of a more operational flavor such as the 
generation and revision of the replenishment order to satisfy target customer service levels and maximum inventory 
constraints. In addition, in order to ensure the validity of the decision support models and prepare the decision makers 
for changes in the market place, the system wfll monitor certain operational indicators relating to the VMR program. The 
indicators and purpose of this monitoring are distinctively different from the monitoring and review function offered at 
the strategic level. 

Sen-through and Demand Orientation Forecasts 

Before we can start to use the system to generate replenishment orders, a set of sell-through forecasts have to be 
developed. We wfll use the models developed in SFP 132 using POS as the primary data source. On the other hand, 
the production planner at the manufacturing vendor needs to know longer term forecasts to plan tor future capacities. 
To that end. the system allows the user to develop and examine not only the replenishment quantity of the next replen- 
ishment cycle but also to extend several periods ahead so that these longer term forecasts can also be estimated and 
used for other (e.g., manufacturing) planning purposes. 

Based on the sell-through data provided by the customer for a given product/product group at a customer DC, the 
system will generate sell-through forecasts including mean and standard donation for any given product at a customer 
DC. The actual forecast algorithm wfll invoke an appropriate one specified in the SFP Module 132 which should con- 
sider trend, and seasonality among other basic aspects of the data stream. In case of a product having too Dttie sell- 
through history, the system will use the product replacement relationship defined to establish more continuous sell- 
through history. In addition, the system win also permit the user to select an appropriate length of historical data to 
account for abnormal sales activities for the product 

The system will also generate longer term replenishment requirements for the demand orientation for a given prod- 
uct so that the user can plan for the longer term demands for the product. To generate medium to long term forecasts, 
the system will first forecast the sell-through for the specified time periods by invoking appropriate forecasting algo- 
rithms in the SFP Module 132. Then, a set of replenishment quantities wfll be generated using the replenishment algo- 
rithm in the VMR module. These replenishment quantities will then become the demand forecasts for the product 

Repleni shment Order Generation 

The generation of replenishment orders is the main functionality of the replenishment planning of the VMR Frame 
250. The main objective of the functionality is to provide the user with an initial set of replenishment quantities for a set 
of products with the consideration of the sen-through forecasts as well as VMR specific operating parameters. The 
quantities will then be approved by the user and converted into actual purchase orders. 

Based on rthe rfore<iaSts of the future setohroughru 

level, maximum inventory level and delivery frequency), and other related indicators (e.g., last reported customer DC 
inventory level), the system will generate a suggested replenishment quantity fa a future replenishment data 

If the product model year changes are regular, then it is necessary to treat the replenishment quantity needed for 
product (or VMR program) initialization and termination differently from the regular replenishments. Therefore, the 
above feature has to be modified to be applicable to these settings: 

Set Initial Replenishment Quantities: The main difference between the initial replenishment quantity setup and the 
regular one is that it may require additional quantities to fill customer DCs or stores. In addition, because there is 
no sell-through history available for these new products, the history for the replaced products will have to be used 
in the confutation. It is also necessary to set a time frame for the confutation algorithm to use a new product's 
data when it accumulates enough data of its own. 

Balance-out at the End of a Season: At the end of a selling season, a product needs to be phased out In such a 
situation, the system will not generate any further replenishment quantities tor the product unless the user decide 
to overwrite the suggested (zero) quantities for a special reason. 



31 



EP0770 967A2 



For a given customer DC, when the products are being considered for replenishment, the system wiD hetp the user 
set joint replenishment orders so that the total cost for the replenishment batch can be minimized. The basic logic is to 
add or delete products included in a replenishment batch to optimally use the transportation means while maintaining 
satisfactory customer service level and inventory level. 
5 The system wiD also automate the replenishment quantity generation for a set of products selected by the user. 
This feature is useful especially when the number of products in the VM R program is relatively large and the user pre- 
fers to work only on exceptional issues rather than examining the details of each product's replenishment activities* 

Replenishment Order Revision 

10 

After the initial replenishment quantity has been generated for each product, the user may be interested in exam- 
ining the entire or only a selected set of products to make sure that the soft information can be reflected in the actual 
replenishment orders. In addition, a number of constraints such as product availability and production capacity wOl also 
have to be taken into consideration. The objective of the features listed below is to help the user revise the replenish- 
15 merrt orders with relevant analysis and search support tods. 

The user can define a set of exceptional report generation criteria so that the system can search for and display the 
products (ailing into the range The sample user-defined criteria wiD include 

Mean and standard deviation exceeding certain limits of the historical norm 

The customer DC inventory exceeding the maximum inventory level after the suggested replenishment quantity 
20 arrives 

For a given replenishment quantity (either recommended by the system or input by the user), the system wiD esti- 
mate and display the probability of stock-outs. To compute the probability value, a search algorithm is needed in addi- 
tion to the relationship between inventory quantity, customer service level and delivery frequency. The user can use the 
feature to evaluate whether the replenishment quantity suggested is satisfactory or not 
25 Most of the replenishment quantities discussed here are appropriate for non-promotional sales. When a promotion 
for a product is planned, the user should be informed so that the final replenishment quantities can incorporate addi- 
tional quantities due to the promotion. The objective of this feature is to identify promotion events during a given replen- 
ishment review period and help the user incorporate additional quantity for the events. 

Before the replenishment orders can be finalized, the DSS 10 will make sure that the vendor can supply the 
30 required quantities in the specified time frame. If the replenishment order shipment date is close to the review date, then 
the product (finished goods) availability will be checked; and if the shipment date is further into the future, then the pro- 
duction capacity will be examined. 

In order to property make tradeoffs between different replenishment Scenarios, the system win estimate the total 
cost (including the inventory and transportation among others) for a given set of replenishment quantities. The cost will 
35 be computed automatically as the user is making modifications in the replenishment orders. 

To reduce the transportation cost, a rough-cut trucMoad planning tool wiD be provided to the user so that the room 
left on a truck can be f Died by other most-needed products for the same customer DC. The underlying logic is to build 
a trucMoad of shipment whenever it is possiUa 

40 Sid€S~ActivityMOT^ 

The movement of product sales reflected in the sell-through data will have different impacts on the future replen- 
ishment activities as well as the methods used to generate recommended replenishment quantities. Therefore, the sys- 
tem will provide the monitoring and tracking capabilities for the user to better manage the sales changes In addition, 
45 the operating parameters specified in the contract will also be monitored so that the user can be reminded whenever 
the replenishment quantities are likely to exceed the limits in the contract. 

The system will compute and maintain the historical norms of mean and standard deviation of sell-through so that 
they can be compared to the similar quantities in the most recent periods. It is an indicator of substantial sales changes 
if the recent sales deviate from the user specified ranges of the historical norms. 
so The system win monitor whether the suggested replenishment quantity is going to exceed the maximum inventory 
level allowed in the VMR contract The user will then be notified to take further action. 

On a regular basis, the system will record a set of tracking signals and compute forecast errors so that when sub- 
stantial changes occur, it should be reported back to the user to take further action. 

55 Distribution Network Design 

The Distribution Network Design Frame 290 supports the Distribution Network Design. 
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Module and Data Space Association 

Figure 25 shows the participating modules and the associated data spaces tor this frame. 
5 Process Row 

The process flow diagram for the Distribution Network Design Frame 290 is shown in figure 26. The Distribution 
Network Design Frame 290 supports the functional requirements identified for the Distrfoution Network Design decision 
process: 

10 

1. Distribution Location Analysis 

The Finished Goods Network Design (FGOND) Module 292 works with the MDA Module 134 and the SFP 
Module 132 to develop a forecast of aggregate long-term demand which is then used to evaluate potential Distri- 
bution Center (DC) locations. The chosen DC locations are then written to Inventory Node 294. 
15 2. Distribution Network Optimization 

The FGDND Module 292 works in concert with the FGIM Module 164 to optimize the overall network configu- 
ration. The result of this optimization is the assignment of demand nodes to DCs and the assignment of production 
nodes to DCs. This information is then written to Supply Chain Network 296. 

20 Data Flow 

The data flow diagram for the Distr ib ut io n Network Design Frame 290 is shown in figure 27. The Distribution Net- 
work Design Frame 290 generates two of the core reports listed earlier, namely, the Customer-DC Assignment 300 and 
the Supply-DC Assignment 302. 

25 

Model Engine and the Modules 

In this subsection, the overall design of the Model Engine 20 is introduced. The objective, scope, and features of 
the seven constituent modules of the Model Engine 20 are discussed. 
30 The Model Engine 20 consists of a Iforary of specialized quantitative models and analysis routines. To address the 
needs of a set of users, a Decision Support Frame calls and assembles these models and analysis routines with the 
appropriate data. 

The number of models and analysis routines within the Model Engine 20 could be quite large by virtue of the mod- 
ular design and inherent complexity of the DSS 10. To better manage the Model Engine 20. there is a need for logically 

35 grouping the models and analysis routines. Furthermore, these models and analysis routines support major decision- 
making areas in a supply chain. Therefore, the models and analysis routines are grouped into seven modules corre- 
sponding to the principal decision-making areas in the supply chain as shown in figure 28: Market Data Analysis (MDA) 
134; Sales Forecasting & Planning (SFP) 132; Vendor Managed Replenishment (VMR) 252; Finished Goods Inventory 
Management (FGIM) 164; Aggregate Production Planning (APP) 162; Component Procurement & Policy Development 

40 (CPPD) 230; Finished Goods Distribution Network Design (FGDND) 292; A frame by virtue of its definition may require 
the participation of some subset of modules (i.e., the models and analysis routines of these modules will be involved). 
In the case of the PSI Planning Frame 160. the MDA 134. SFP 132. FGIM 164. and APP 160 Modules will be involved 
in constituting the decision logic 76. 

In many cases, the same models and analysis routines may be employed by distinct frames in different contexts, 

45__ where the relationships between the models and the associa ted data linkag es vary accordin gly. This requires that the 
Supply Chain Frame Manager 24 interact directly with the models and analysis routines in the Model Engine 20. The 
models and analysis routines win therefore have standard data and logic input/output (I/O) formats. The standard I/O 
formats win also facilitate the maintenance of the individual models and analysis routines, e.g., updating and replace- 
ment 

so In addition to the seven modules defined above, there Is also a group of general purpose numerical routines that 
are not specific to any of the above seven modules. These routines are collected into a design element referred to as 
the Model Engine Utilities 22. as shown in figure 1 . Examples of the Model Engine Utilities 22 include generic linear pro- 
gramm'ng solvers, and statistical analysis routines. 

Table 7 lists the modules in the DSS architecture for the two supply chains. 
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Manufacturing Supply 
Chain 


Equipment Repair Supply 
, Chain 


Market Data Analysis 
(MDA) 


Market Data Analysis 
(MDA) 


Sales Forecasting & 
Planning (SFP) 


Sales Forecasting & 
Planning (SFP) | 


Finished Goods 
Inventory Management 
(FGIM) 


Finished Goods Inventory 
Management (FGIM) 


Aggregate Production 
Planning (APP) 


Aggregate Production 
Planning (APP) 


Component Procurement & 
Policy Development 
(CPPD) 


Component Procurement & 
Policy Development (CPPD) 


Vendor Managed 
Replenishment (VMR) 




Finished Goods 
Distribution Network 
Design (FGDND) 





Table 7 

Modules in the Manufacturing and Equipment 
Repair Supply Chain 



Market Data Analysis (MDA) 1 34 

The MDA Module 134 contains quantitative models and computational routines that compile and synthesize hybrid 
sources off market information to support Sales Forecasting & Planning, and VMR. The models and routines of the MDA 
Module 134 are used in support of Demand Characterization, Bottom-up Forecasting, Top-down Forecasting, Sales 
Promotion Analysis and Vendor Managed Replenishment The models and the routines in this module are used to: 
Analyze relevant industry data from various sources; and Provide quantitative analyses of sales. 

Scope and objective 

Objective: Compile and synthesize hybrid sources of market information for the purpose of sales forecasting and 

planning, and VMR. — — — 

Scope: Industry-wide, company specif ic and point-of-sale data. 

Features: Analyze relevant industry data from sources such as Nielsen and El A (Electronics Industry Association); 
Develop customer and custom er^oduct profiles; Maintain promotion calendars of major customer and the enterprise; 
analyze promotional effects; and Provide quantitative analyses of sales at retail outlets whenever point-of-sale data are 
availabia * ~" 



Demand Characterization 

The models and routines in the MDA 1 34 module to support demand characterization in the commercial setting are 
equally applicable to support requirements characterization in the defense setting. 

For national defense applications, the actual repair item usage data correspond to the POS Data 138 in the com- 
mercial setting. Analysis for POS Data 1 38 can be performed on the repair item usage data to characterize demand for 
various parts. Furthermore, in order to intuitively access relevant repair item-related data and information, the relation- 
ship among different parts has to be established. To that end, we will develop a tree structure to represent the bid of 
material where each node of the tree corresponds to a repair item, and each arc represents a parent-child relationship. 
For ease of presentation we employ commercial nomenclature in the following section 
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Analysis Routines tor Demand Oiaracterization 

In the following, we describe three types of analyses that will be performed on industry survey data. Demand His- 
tory Data 1 36. and Point-Of-Sales Data 1 38 to characterize the demand tor the products (or services in defense appli- 
cations). There are other types of analysis that can be performed on these data sets which wffl be tiscussed separately 
when each individual data set is being considered. 

Product Family Composition Trend and Percentage 

This involves the analysis of the trends in quantity and percentage of each product family over a given period of 
time of the time series. The input of the analysis routine is the set of time series corresponding to the product families 
and the associated product family names. The output ts the trend of the quantity, and composition percentage for eadi 
individual product femfly. For example, Table 5 below provides the percentage changes tor major color television prod- 
uct families (13"-14*. 15"-24*. 25". 26' and 2T a above televisions) from 1988 to 1994. 





"ii'- 


15 








27-* 


1988 




sr. 


"StT 


6.05% 




■ 4.18% 


1989 


24.98* 


54. 


"Sift 


7.28% 


5.01% 


7^87% 


1990 


22.12% 


54. 


79* 


8.06% 


4.56% 


10.47% 


1991 


"i3.68% 


49. 


■531 


10.53% 


3.90% 


12.96"* 


1992 


20.62% 


48. 


iall 


13.29% 


3.40% 


14.51% 


199* 


19.13% 


45. 


12% 


1$ . 87* 


2.16! 


■17\78% 


1994 


18.57% 


41. 


"58* 


17.58% 


1.55% 


20.71% 



Table 8 

Sample Product Family Composition Change from 1988-1994 



Pareto Analysis of Sales 

The analysis involves the plotting of the percentage cumulative sates levels vs. the percentage of total number of 
products to determine the ABC classification of each product as illustrated in figure 29. 

Objective 

To identify the products or customer that contribute the most to the overall sales or production volume. To establish 
- the ABC classification of products (or customers); — 

Input 

POS Data 138. Shipment a production data. 

45 :— _ _ - ~ 

Output 

Plot of the cumulative percentage sales (or production) levels vs. the percentage of total number of products or cus- 
tomer generating this sales (see figure 29). 

Algorithmic Steps 

Rank products or (customers) in decreasing order of sales. 
Starting from the top of the list compute: 

cumulative sales 

cumulative number of product (or customers) 

Plot percentage of cumulative sales as a function of percentage of total number of products (or customers). 
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In addition, another scatter plot can be drawn to show the volatility vs. sales (where measure of the volatility is the 
coefficient of variation) as shown in figure 30. Each point in the second plot corresponds to a product (or product family), 
and the result of these two plots can be used to develop differentiated inventory control policies tor products with differ- 
ent demand patterns. 

5 

Correlation Analysis Among Product Families 

This involves the analysis of the correlation among the time series correspond rig to different product families. The 
input of the analysis routine is the set of time series corresponding to the product families and the associated product 
10 family names. The output is the correlation coefficient for related product families. 

Industry Survey (El A) Data 

Electronics Industry Association (EIA) collects manufacturer to retailer Demand History Data 136 monthly from ail 
15 major consumer electronics manufacturers. After consolidation by EIA, the data are sent back to the manufacturers for 
their own usage in analyzing industry wide sell-in activities. The data may be obscured by temporary stocking and other 
short-term dealings between individual manufacturers and retailers, and they are usually a few months lata Therefore, 
the data are normally not suitable tor short term demand characterization and forecasting. However, for longer term, the 
data are usefuS in revealing trends and changes in the sales of overall and individual product families. The three types 
20 of analyses descrfced herein can be performed on the EIA data to monitor the long-term demand level and composition 
changes. 

Demand History Data 

25 Not ail retailers are capable of collecting and providing the POS Data 138 to their manufacturer suppliers. For this 
reason, more traditional Demand History Data 136 should be analyzed to characterize the demand tor the manufac- 
turer's products. We realize that the demand data are a reflection of the customer demand but they can be altered by a 
number of factors. For instance, meeting the quarter-end sales target or taking advantage of temporary sales promotion 
deals may make true consumer demand tor the products less apparent Nevertheless, the Demand History Data 136 

30 are an important source of demand information that can complement the short term demand information from the anal- 
ysis of POS Data 138 and the long term demand information obtained from EIA data. In general, Demand History Data 
136 are more suitable to analyze the medium term sales level and trend information. The three analysis routines 
described herein can be applied to the Demand History Data 136 to derive the medium term sales level and trend 
change information. 

35 

Point-of-Sales (POS) Data 

Major retailers are now collecting the sales transaction data from the scanners at the sales counter and sending 
the data to their manufacturer suppliers after summarization. The data directly reflect the consumer demand for the 
_ 40. ... rnanufacturer's products and response to sales promotions. Jhey can serve as signals to the changes in sales trend- 
and consumer reactions to marketing efforts. In essence, the POS Data 138 can be used to detect short term sales lev- 
els and their changes tor the manufacturer's products at various retailing outlets. The three types of analyses described 
herein can be performed on the POS Data 138 to monitor fre short term demand levels and their ongoing changes. 

The inventory status represented in the POS should be verified in order to be used to assess the supply chain firv 
45 ished goods inventory situation. Shipment quantities from the manufac ture r to the r et ailer are determined by consumer 
demand, and retafleTs inventory carrying polides, among other influenfiaTfactors whfle the POS Data 138 are much 
more direct in reflecting the true consumer demand. The following three analysis routines will be applied to POS Data 
1 38 in addition to the three general ones mentioned herein. 

so Inventory Status Verification 

To verify the inventory status, the POS Data 1 38 can be used in combination with the shipment data, and the inven- 
tory balance equation to compute the deduced inventory status. Then, the deduced inventory status can be compared 
to the reported inventory status. 

55 

Inventory Protfe 

The inventory profile corresponds usually to the management decision of an organization, and can be used to 
judge the over- and under-stocking situation along the supply chain The normal inventory prof fle for each product and 
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customer combination wiQ be captured and stored so that it can be later retrieved and compared to the current and 
future (projected) inventory profiles to determine the possible over* and under-stocking situations. 

Detection of the Changes in POS Data 

5 

The normal sales levels and associated variance intervals can be either calculated from the POS Data 138 tor a 
given product by a customer, or specified by a user who is knowledgeable about the sales activities fix the product 
When the sales level fluctuates beyond the normal sales variance intervals, the tool can detect and report the excep- 
tions automatically. 

to 

Volatility of demand 
Objective 

15 To measure the volatility of demand. The volatility of demand can be measured by the coefficient of variation of the 
demand. The coefficient of variation of a random variable is equal to the ratio of the standard deviation to the meaa A 
large value of the coefficient of variation indicates that the standard deviation is larger than the mean; the demand is 
thwefere very volatile. While a small value of the coefficient of variation indcates a stable demand (low levels of vola- 
tility). 

20 

Input 

POS Data 1 38 or Shipment data by product (product group) or customer (customer group) 

25 Output 

Volatility measure C$. 
Algorithmic Steps 

30 

Compute mean of demand: 



35 




Compute standard deviation of demand: 

- 40 " 



45. 




Compute coefficient of variation: 



50 




Lumpiness of demand 

55 

Objective 

To measure the level of lumpiness of demand. The lumpiness is a measure of the time dispersion of demand. A 
demand pattern is said to be lumpy when the demand is c oncen tr at ed in only a few number of time periods with numer- 
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ous periods with no demand. 
Input 

5 POS Data 138 or Shipment data by product (product group) or customer (customer group) 
Output 

C] the fumptness measure. 

to 

Algorithmic Steps 

C| a the percentage off the total number of time periods with demand equal zero 
is Demand pattern changes 
Objective 

To detect rapid changes in level and variability of sales. 

20 

Input 

POS Data 1 38 or Shipment data by product (product group) or customer (customer group). 
Range tor "normal" sales level and variability. 

25 

Output 

Exception signal indicating a normal change in sales levels. 
30 Algorithmic Steps 

Compute normal sales levels and associated variance from the POS Data 1 38 for a given product by a customer. 
Alternatively user sets range for normal sales level and variability. 
Compute actual level of sales and variance each period. 
35 When the sales level fluctuates beyond the normal sales variance intervals, detect and report the exceptions. 

Demand history trend 

Objective 

40 

To characterize demand by trend and level parameters. To assess changes in the dynamics of demand based on 
changes in trend. 

Input 

45 

POS Data 1 38 or Shipment data by product (product group) or customer (customer group) 
Output 

so Estimation of trend and level. 
Algorithmic Steps 

For variable X, over time period 1=0 to a 

55 
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Compute trend (b) and level (a) parameters: 



b«n £ (i-t+n)X r n 



10 



15 



20 



25 



30 



MODEL 


WHERE USED 


Volatility of demand 


Demand Characterization 

PSI 

VMR 


Lumpineea of demand 


Demand Characterization 

PSI 

VMR 


Demand pattern changes 


Demand Characterization 
Bottom-up Forecast 
Top -down Forecast 
VMR 


Demand history trend 


Demand Characterization 


Pareto analysis 


Demand Characterization 

PSI i 


Table S 
Usage of MDA 


• 

Models 



Sales Forecasting and Planning (SFP) 132 

35 The Sales Forecasting and Planning Module 132 contains all the models and routines that are used to generate 
forecasts. These models and routines are used in the Demand Management Frame 130 tor Bottom-up, Top-down fore- 
casting, for the analysis of sales promotions and to estimate forecast accuracy. The SFP Module 1 32 is also used in the 
VMR Frame 250. 

The models and routines of SFP 132 fall into three categories: generic models common to the manufacturing and 
«r reparerrvirohments; models specific to the manufacturing enviw^ 

Scope and objective 

Objective: Develop top-down and bottom-up sales forecasts. 
45 Scope: Products and selected customers. 



Features: Statistical forecast based on historical sales; Statistical forecast based on point-of-sale data if warranted; 
Customer provided forecast and orientations; and Reconciliation tools to support expert judgment such as excep- 
tion flags and sanity checks. 

so Models Common to Manufacturing and Repair Environments 

Three types of generic models are common to the manufacturing and repair environments. The first type consists 
of the various statistical forecasting models that can be used to forecast any time series (demand or consolidated 
requirement). The second type concerns the estimation of seasonality factors based on the same approach in both the 
55 repair and the manufacturing environments. The third type of model relates to forecast accuracy estimation. 

Statistical Forecast Models 

The objective of the Statistical models is to generate a forecast based on the projection of some historical charac- 
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tff tstics of the time series. These models can be applied to any time series in the context of demand characterization, 
bottom-up, top-down forecasts and VMR 

Below we discuss the following models: Moving average; Linear trend; Exponential smoothing; Holt-Winters model; 
Winter^ method; Regression based forecasting model; and AutoregressrvBtawving average model (Box Jenkins). 

5 

Moving Average 

This conventional model is appropriate when the dependent variable is assumed to fluctuate around a constant 
(stationary) average value, i.a: 

w 

X t »p + e t .t»1A... 

where pis an unknown constant corresponding to the mean of the series and % is a random error with mean zero and 
variance o 2 Moreover, the model assumes that the variables {ej and hence { XJ are independent 

is 

input 

Time sen es data to be forecasted (for example POS or shipment) 
Window n: number of periods to be considered for averaging. 

20 

Output 

Future forecasts and their variances. 
25 Algorithmic Steps. 

Compute next period forecast based on the average of the last n periods 



30 




35 Estimate o 2 for o 2 : 



d»-^--E-w i -: 



var (F t>1 - X M ) = a 2 (n+1)/ri. estimated by i 2 ((n*1)Ai) 
Linear Trend 

This conventional model is appropriate when the dependent (forecastable) variable is assumed to fluctuate around 
a trend line, specified as a linear formulation of time, I. a X , = a ♦ bt+ e t where e, is a random error with mean zero and 
5a variance o 2 . As above, fa } and hence {XJ are assumed to be independent The model may be viewed as a special case 
of the regression based models below, with "time'' as the only explanatory variable . 

Input 

55 Tune series data to be forecasted (for example POS or shipment) window n. 
Output 

Future forecasts and their variances. 
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Algorithmic Steps 

Select appropriate time period for trend estimation (the Window* of n periods). 
Compute trend and level parameters: 



Estimate forecast based on trend projection 

F^=a4*(t*l) 

Estimate variance of forecast 



Exponential Smoothing 

This conventional model is appropriate when the dependent variable is assumed to fluctuate around a constant 
(stationary) average value, i.e.: 

X t «p + et,ta1.2,... 
It puts progressively smaller weights on more remote observations from the past 

F t ;r- aXj+ aO-aJX^* cft-a}*-^ 

Input 

Time series data to be forecasted (for example POS or shipment) 
Smoothing parameter ~ 



Output 

Future forecasts and their variances. 
Algorithmic Steps. 
Initiate F t asDo. 

F t*i -aDj+O-aJF,. 

Estimate variance of forecast 
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Estimate variance of forecast error » Var (F^, - X M ) 3 (o 2 ) 2 /(2-a) 



Holt-Winters model 



10 This conventional modd is also appropriate when the dependent (forecastabf e) variable is assumed to fluctuate 
around a linear trend One. i.a when X, is specified by: 

X t »a+txt+e t 

15 with the associated assumptions regarding e. As with exponential smoothing, progressively smaller weights are attrib- 
uted to more remote observations. 

Inputs 

20 Time Series Data to be forecasted (for example POS or shipment). 
Smoothing parameters 1>c£P>0. 

Outputs 

25 Future forecasts and their variances. 
Algorithmic Steps 

Initial So and intercept and slope of trend line. 
ao Update recursively 

S t «~oX t +(1-a)S M +G w 

35 

Set 

_ _ F __ B $r|rtQl 

F t n aD t + a(1+p) (1-a) X M + a(1-a) (1-a-ap) X t . 2 ♦ a(1-a-ap) (1-a) 2 X t . 3 + a(1-a-a» (1-a) 2 X M 
Var (FJ » a 2 fa 2 + (1+P) 2 (1-a) 2 + a(1-a-ap) 2 (1-a) 2 /(2-a)} 



45 



50 



Estimate variance of forecast <? by 



3^-2-? [X r G e i -7-1/2 ( M) G,) 2 



Estimate variance of forecast error by: 

Var (F t ^ - 0 M ) « a 2 [Ua 2 + (1+P) 2 (1-a) 2 + (a(1-a-ap) 2 (1-a) 2 y(2-a)} 
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Winters method 

This conventional model is appropriate when the dependent (for ecastaWe) variable ie assumed to fluctuate around 
a linear trend line modulated by seasonality factors, La 

5 

|i is the initial deseasonaiized level. G the trend or slope cornponerrt and c, the multiplicative seasonality factor. Assume 
that the season consists of N periods* La c, ° c,^ for ail t. The seasonality factors are normalized such that: 

10 

is Winters' method uses three smoothing factors, a, p and y as Mows: 
Inputs: 

Time Series Data to be forecasted (for example POS- a shipment). 
20 Season length N. 

Smoothing factors, a, p and y. 

Outputs 

25 Future forecasts and their variances. 
Algorithm Steps 

Step 1 : (Initialization). Use first two seasons (periods • 2N+1, -2N+2 0) to initialize values: 

30 

1a: Calculate sample means for two separate seasons of data 



35 



AO 



lb: Define Gq => (V2 - V1)7N as the initial slope estimate. 

1c: Set Sq » V2 + Qq (N-1J/2. as an estimate of the value of the series at time t=0. 

45 1 d: Compute initia l estima tes of se asonal f actors; thes e are obtained by dividing each of the initial observations 

by the corresponcfing point on the line connecting V, and V 2 , La, compute: 

C, = Xj/RV, - (N*1)/2-i)Gol. i = -2N+1 0 

so te: Average seasonal factors as computed for the two seasons 

n»i 2 ' * * " 9 0 2 

55 

1f: Normalize seasonal factors: 
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5 

Step 2: Update recursively: 

S f o afX/C^) ♦ (1-a) (X M * Q M ) 

to 

Qi-PISi-S m ]+(1W0h 
Ct-yP/SJ+O-^C^ 
is Step 3: Create forward forecast in period t for period t+r 

Regression based forecasting models 

20 

In this conventional model, it is assumed that the torecastable variable X is determined by mfcl) exogenously 
measurable (torecastable) variables 7P\ as follows: 

25 

where {ej are independent with mean zero and variance o 2 . 
Inputs 

30 Time series for fXJ and all explanatory variables 0 % \ 7™ Z< m >} For example market share, total market value. 

installed base. GNR etc. 

Time series data to be forecasted (for example POS or shipment) 

Outputs 

35 

Estimates of coefficients a. b v bz b^ as well as o 2 . 

Forecast for future value of X. on the basis of estimated future values of Z* 1 *. Z* 2 * Z< m >. 

Algorithm Steps 

40 

Use of standard multiple regression method. 

Autoregressive / Moving average model (Box Jenkins) 

45 In this category of models, it is assumed that the torec astable varia ble fXt ) exhibits an autocorrelated structure. The 

most general model of this type is specified as an ARM A (p.q) 
model, i.a 

X, 3 p t x t i + P s X n*-Pp x *p*«i 

so 

Where 

«l a T i«H+T2 € l-2 + T q e |H ,+U l 

55 with {uj independent with mean zero and variance o 2 
Inputs 

Time series data to be forecasted (for example POS or shipment). 
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Outputs 

Identification of optimal values of p and q. 

estimates of coefficients p A fip and y fl ...,T q as well as o 2 . 

5 Forecast of future vafua 

Algorithmic Steps 

Standard Bca-Jenkins Algorithm and Process with forecasted value computed as follows: 

10 



15 

Seasonality factors estimation 
Objective 

20 

To estimate far each time bucket (quarter, month, week) its percentage of the yearly voluma 
Input 

25 Historic data by aggregated at the same level as the seasonality 
POS 

Shipment 

Total market volume, etc 
$0 Output 

Seasonality factors for each time bucket. 
Algorithmic Steps 

35 

Compute for each time bucket the proportion of the yearly volume it represents. 
Forecast Accuracy Models 

40 To estimate the aocuracy of the various t y pes of forecasts. Measu res of forecast accuracy are used in various con- 
texts. 

It is a proxy measure for the variance of the forecast when this one cannot directly be computed. Forecast variance 
is used in several inventory and safely stock calculations. 

Forecast error measures can also be used to identified those products and customers for which demand patterns 
45 are particularly unstable and thus require special attention. 



Forecast error calculation 
Objective 

flflL . _ ._ - 

To compute forecast error for the forecast produced n periods ahead. 
Input 

55 Actual Sales 

n periods ahead Sales Forecast (BU, TP, etc.). 
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Output 

Average Absolute Error as of percentage 
Mean Square Error 
5 Table of forecast accuracy as function of n 

Algorithmic Steps 

Confute the percentage difference between the forecasted and actual sales. 
10 Compute average absolute error and mean square forecast error. 

Exception report generation 

Objective 

15 

To generate the list of the products or customers for which the forecast error was greater that a predetermined fore- 
cast error threshold. 

Input 

20 

Average Absolute Error 
Mean Square Error 
Forecast error threshold 

29 Algorithmic Steps 

Rank list in decreasing order of Average Absolute Error or Mean Square Error 

Output 

30 

Exception list: ordered list of products for which the forecast error was higher than the threshold 

Models Specific to the Manufacturing Environment 

$5 The particular aspects of the manufacturing environment call for specific models in the area of forecasting and plan- 
ning. In particular a forecast approach that specifically models the ordering pattern of retailers based on their replen- 
ishment policy and level of sale to the final consumer is considered. Approaches for the modeling of sales promotions 
are also proposed. 

40 Expert based mode! for Bottom-up forecast 

This discussion describes an algorithm to compute bottom-up forecasts designed so as to result in the best avail- 
able point estimates of sales as well as a characterization of the degree of uncertainty surrounding these estimates. 
The system develops forecasts for each account each model and each time-period. These are subsequently aggre- 
ss gated over ail acco unts. • ^_ 

The analysts starts with a characterization of the account's anticipated sales pattern for a given model. Its order to 
the manufacturer are obtained as derivatives of this sales pattern, assuming that a specific systematic replenishment 
policy is followed by the account The prevalence of a systematic replenishment policy On the absence of capacity prob- 
lems) is an important assumption but one which we have verified in our analysis of real retailer's behavorior. 
50 Previous investigations of point-of-sales data have established that the accounts' sales pattern is much more pre- 
dictable and regular than the normal order stream. It is therefore appropriate to start the forecasting process with a 
characterization of the account's sales pattern. Moreover, we envision that the inputs to the system be provided by the 
retailer in cooperation with or as a result of monthly meetings with account representatives (buyers, logistics manag- 
ers). The account representatives are clearly more familiar with their sales pattern than the resulting order stream to 
55 their supplier; their estimates for future orders are dearly driven by their anticipation of future sales. 

The need to characterize the uncertainty of the manufacturer's model sales stems primarily from the fact that this 
characterization is to be used as the foundation tor inventory planning, i.e. the determination of the so-called Mine or 
lower bounds for the Mine required to assure customer service levels which are compatible with the manufacturer's 
Quick Response targets. 
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To assess minimum inventory requirements one needs to characterize cumulative sales over time rather than or in 
addition to sates per month. Extreme care needs to be exercised in aggr e g a ting sales over consecutive months since 
these are highly correlated. Thus, a straightforward convolution of orders in consecutive months would lead to serious 
underestimates of the variability of cumulative orders and hence to the determination of inappropriately low safety 

5 stocks (minimum inventory levels), exposing the manufacturer to undesirable frequent stoctouts. These would result in 
inappropriate customer service, loss of market share and last but not least, a continuation of the vicious cycle prevent- 
ing the manufacturer from establishing reliable forecasts in the first place. 

Our approach provides an exact characterization of the statistical distrfcution of cumulative sales based on a given 
characterization of the underlying sales pattern. 

10 The calculus used to characterize the distributions of account orders and aggregate orders is based on simple but 
rigorous probability calculus. 

The system is intuitive and fufly transparent to aO users. Below we give a brief outline of the inputs required by the 
system and the user interfaces which we envision developing to provide the user with various types of background infor- 
mation to facilitate the task of specifying forecast inputs, 
is The calculus used to derive all order and aggregate order cfistrfcutions is explained. 

Required inputs; user interfaces 

The user wiO be respons&le for entering forecasts for specific account/model combinations under his/her respon- 
se sibifrry. For any given account/model combination, forecasts are to be provided for the next 12 months on a roiling hori- 
zon basis. The user wifl be confronted with a main menu permitting a choice between: (I) whether to provide estimates 
of the accounts' sales (11) or orders (B); and (II) whether to provide estimates of monthly total sales (orders) (111) or to 
provide separate estimates (IK) for 

25 (a) regular sales activities, and 
(b) Promotional activities 

We will strongly encourage LAMs to opt for 

30 (1) providing estimates for sales, and 

(2) providing separate estimates for regular and promotional sales 

If option (12) is chosen, the calculations described below will be circumvented and by default orders in consecutive 
months will be treated as independent. (This may result in important distortions as explained in the introduction but is 
35 unavoidable under this option; the user cannot be expected to estimate the intertemporal correlation pattern. It is con- 
ceivable that an "average* correlation factor may be inferred from historical orders.) 

AO accounts managed by the three LAMs whom we have interviewed follow or would like to follow a sinple replen- 
ishment policy of the following type: (a) the model's inventory position is reviewed periodically (e.g. once a week, once 
in two weeks, once a month); and (b) at review epochs the account places an order to increase the model's inventory 
40 p osition to a tar get level of a given number of weeks of future expected demands (e g 6 weeks. 8 weeks) unless the 
current inventory position is already above this target level in which case no order is placed. 

The formulae below are based on this type of replenishment policy which is characterized by two parameters only 
(the review period and the target order-up to level in weeks). This policy structure is easy to use and efficient from more 
than one point-of-view. However, it will be easy to make appropriate modifications should it become apparent that other 
45 types of replenishment poficies are used by some accounts. 



Inputs 

s^ sales in period t (random variable) 
so h a E% 

W a number of periods of future demands to which the inventory position is to be increased every time an order is 
placed 

The distribution of s, is obtained by fitting an appropriate distribution to the three point information provided by the user. 
55 We fit a shifted Binomial distribution: Let 

St™*" = minimum sales for period t 

S," 1 " o maximum sales for period t 

S," 10 " »most likely sales volume for period t 
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Let Sf 1 *" and assume 5, is Binomial (n.p) with n - S l na *-S, ,r 

[«P ♦ d-P)l+l - a , M . *g. p a (a""" 1 ,-s , ^ -l)/h 
s ([x] -denotes the largest integer smaller than or equal to x) 
Outputs 

o,» order in period t 

10 

is 

o» a cumulative orders in periods 1 ,...,t 

IP t o inventory position at end of period t after placing an order (a inventory on hand + outstanding orders) 

T t • target order-up to level at end of week 

20 



t » 



28 



The following recursive relationships hold (assuming bacMogging; the equations are easily adjusted for the cost of tost 
sales) 

°t=PVIP«.i+S,f (2) 

35 

We assume here that the s, - variables are independent of each other. 
Calculating IP, and o, • distributions 



40 The distrfcution of the IP, - variables can be computed recursively Observe the IP,7f anrfs, are independent of each - 
other. 

ProbtIP, « T,| IP M » I] - Pr[s t * I - T J (4) 
. 45 Hence, • — 



ProbtIPt-Tj - 



(5) 

55 

Fbrl'>T v PrOb(IP t » r | IP H =Q = Probfa = I - r] 
Hence. 
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ProbllP, • l'J • 

SPxobl IP e . lA < n =l] -PzoblS t *l-l') 
e-X.J 



(6) 



Prob(o t »0|IP H aq»Prab[& t £l-T t ] (7) 



Probto. - 0] » 



(8) 

Calculating Cumulative Oder Distributions 

The distributions of cumulative orders, i.e. the (0j) - distribution can be computed recursively as well but only by com- 
puting the joint distribution of and IP^ : 

Case 1 Let k^k: 

PrtO^kandlPt-TJO^ »klP M =l]oPrts t ok , -K + l-T l l (9a) 
PitO^tfandlPj-riO^klPM =l]o0 (9b) 



tor all I^ T, 



Case2k*ak: 

Pr[O t « k and IP C - 1* | 0 M - k and IP t . x = 1] =» 



(pr [Sc-i^l'Tif r e -*l'«r 
\ 0, otherwise 



(10) 



Thus 

PrlO, a k* and IP, = TJ a Pr[0 M « K IP H -I 
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Pr[s t - *'-*n-T e ] ♦ £ Prl0 6 „ x =k' and JP e . x = D Pr[s t l-T t ] . 

Pz lO e =/e' andlP^ll 

(IX) 



ro 

PiPm »KandlP H »Q. 

Prfs t «l-n (12) 

15 

Past Promotions Effects Estimation 
Objective 

20 To assess the total impact on sales of past promotions. 

Promotions perturb the regular pattern of sales and various types of promotional activities influence the sales vol- 
umes according to rather different patterns. The objective of the model is therefore to assess the pattern of the impact 
of the promotion over time. 

& Inputs 

Times series of sales. 
Time period of the promotion. 
Class of the promotion. 
30 Type of the promotion. 

Intensity of the promotion. 

Outputs 

35 Overall impact of the promotion 
Profile of the impact over time. 

Algorithmic Steps 

40 The model is based on the use of time series models First an analysis is applied to a "censored* time seric&of 
sales volumes, in which all promotion (and after promotion) periods have been eliminated. One of several basic time 
series models is applied to identify trend factors, seasonality indices and/or auto correlation structures These basic time 
series models include exponential smoothing (weighted) moving averages. Winters' model. Box-Jenkins models. The 
following Modified Winters* Procedure uses the demand (POS a shipment) data to remove seasonality and trend 

45— effects. — 

Select time series model for estimation of demand for non-promotion periods. 
Initial Estimation of Level (including trend) at each Historical Period. 

Calculate the moving average of seasons, with each season having period P. If P is an even number, take the average 
of two consecutive moving averages to let the estimate centered on the time period. 

so 

Estimate Seasonal Factors. 

Divide the actual demand by the centered moving average to obtain the estimate seasonal factor. Dampen the ran- 
dom effects by taking averages for similar periods in different years. Then, normalize the estimate seasonal factors that 
55 totals to P. Using the normalized seasonal factors remove the seasonality effects from the demand data. 

Estimate Level and Trend Terms. 

Using the regression equation algorithm specified in the MDA 1 34 module, find the regression parameters for level 
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and trend coefficients to fit the regression One. Using the regression coefficients remwe the trend effects from the 
demand data. 

After an appropriate time series model has been selected for all non-promotion periods, interpolate base-One sales vol* 
umes in the promotion periods which would have arisen in the absence of the special promotion activities. 
Calculate the ratios of the actual sales volumes during the promotion periods and the calculated "base One" values, for 
each promotion period separately. This defines the i opart curve of tie promotion. 

Aggregate the impact curves pertaining to different promotion periods of a given type into a single curve using standard 
curve fitting techniques. 

The resulting impact factors for each of the periods belonging to and following after a promotion interval can now 
be used in future forecasting efforts. 

Future Promotion Impact Estimation 

Objective 

lb estimate the impact of a future promotion 
Inputs 

Tune period of the promotion 
Class of the promotion 
Type of the promotion 
intensity or me promonon 

Outputs 

Estimated overall irrpact of the promotion 
Estimated profile of the impact over time. 

Algorithmic Steps 

Search promotion calendar for past promotions with similar characteristics. 
Assess impact of the planned promotion based on computed effect of similar past promotions. 
Identify generic prof le of promotion irrpact corresponding to the planned prom ot ion . 
Compute estimated profile of the planned promotion by combining estimated total impact and generic profile 

Analyze Promotion Effects 

This analysis includes the following three types of promotional activities: price promotions, where the Hern price is 
—reduced by a given percentage for a limited period of time (e.g.-1-2 weeks); promotions via feature advertisements; and 
promotions via special store displays. 

The characterization of the impact of promotional activities is to be used as the basis of the statistical forecasting 
procedures in the Forecasting module of our OSS 10. It wiD also be invoked as guiding information in the bottom-up 
forecasting procedure. 

The sales promotion- activities perturb the re g ular sale s pattern in the commercial settin g . Correspondingly, s pecial 

events such as scheduled exercise in the defense application will also significantly change the usage of parts. There- 
fore, the models developed for analyzing the effects of sales promotions will also be applicable in understanding the 
effects of the special events in the defense setting. In the following section we employ commercial terminology for ease 
of explanation, while the models are equally applicable to both the defense and commercial applications. 

It is both intuitive and extensively substantiated by several statistical studies in the conventional marketing literature 
(see e.g.. Blattberg and Naslin (1993)) that the various types of promotional activities influence the sales volumes 
according to rather different patterns. Price promotions typically result in a significant increase in the sales volume dur- 
ing the course of the promotion period The increase in the sales volume is due to: 

a. consumers increasing their normal purchase quantities to take advantage of the temporary price discounts; 
tx consumers making a purchase during the promotion period who otherwise would have waited until a future point 
in time; 

c. consumers being enticed into a purchase who otherwise would have opted for a different brand or who otherwise 
would not be in the market for this Hem. 
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10 



Only factor (c) results in a sgrificant long term increase of the sales vofuma The first two factors (a) and (b), on the 
other hand, cause an Increase of the sales volume during the promotion period, but the increased volume is partially or 
completely compensated for by a decline in sales after the promotion period. 

Figure 31 displays a typical pattern for the percentage increases over time, resulting from a price promotion. As 
mentioned, the percentage increase is positive during the promotion period; the magnitude of the impact first increases 
and then decreases. The promotion period may be followed by an interval of time with a negative impact; the magnitude 
of the decGne first increases and then decreases. See LewandowsM (1 985) for more details. 

The impact of promotions via feature advertisements or special in- store displays may exhibit a similar pattern (as 
in figure 1 8); alternatively the impact of these types of promotions may be confined to the promotion period itseH. 

Regression Models 



Our menu of regression equations consists of variants of the following basic equation used in Blattberg and Wis- 
niewsM (1988) and with minor changes in WHtink et aL (1987). 
is Let 

$h a Weekly retail sales for item I at timet 
Rn a The regular (sh eif) price of item i at time t 
P H « The observed price (actually paid by the consumer) for item i at time t 
20 O rt a The deal discount for item i at time t ((RjrPjJ/Fy. 

CPp = The price of a competitive item j at time t with j not equal to i. 

Xk « A dummy variable which equals 1 rf a dsplay is run for item i at time t, 

Yr a A dummy variable which equals 1 if a feature ad is run for item i at timet 

Lh a A variable representing deal decay, equaling kj-1 with j being the time since the beginning of the deal and 
25 0<k<l. 

The basic regression model is: 

S tf =exp{a 1 *a 2 fl tf +a 3 D tf +E > 6 i CP^+a 4 X ft +a 5 V A +o 6 L tf ) (1) 
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All of the data required for this model are available in our data sources. The only possible exceptions are the CPj t -num- 
bers which reflect prices charged for items provided by competing vendors. We foresee that the latter may not be avail- 
able in some commercial supply chain settings, if so. the item IfiCP jt is eliminated from equation (1). On the other 
hand, a trend and seasonality factors (expressed e.g. via indicator variables) may be added to equation (1). For exam- 
ple, if the year is divided into four distinct seasons, add the variables Zjf 1 if period t is part of season I (M.K, 3) (along 
with a trend term) to the right hand side of (1): 



~40~-The fog-linear tornru^ 

simple linear formulation. The specification in the conventional Blattberg and WisniewsW model implicitly assumes that 
the impact of a promotion is restricted to the promotion period itself and that the magnitude of the impact exponentially 
declines over time. To allow for a general pattern of impacts as in figure 30. we are considering the following variant Let 
denote an upper bound on the number of periods over which a price promotion exercises a significant impact and let 
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U,t ai H period t arises I periods after the beginning of the last promotion period. 
1=1. K. u 

Sj>«a^ & *«,4 ie Hg P^) (l+a,I> ie ) *« 4 X ic +« 9 r ic j 



(3) 



The coefficients of the above regression equations will be determined by using the generic regression routine specified 
elsewhere herein. 
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Time-Series Models 

An artematrve approach to analyze retailer promotions is based on the use of time series modeis. First an analysis 
is appfied to a "censored - time series of sales volumes, in which aJJ promotion (and after promotion) periods have been 
s eliminated. One of several basic time series modeis is appfied to identify trend factors, seasonality indices and/or auto 
condition structures. These basic time series models include exponential smoothing (weighted) moving averages* Win- 
ters' model, Box-Jenkins models. The following Modified Winters' Procedure uses the demand (POS or shipment) data 
to remove seasonality and trend effects. 

10 Step 1 . Initial Estimation of Level (including trend) at each Historical Period. 

Calculate the moving average of seasons, with each season having period RHP is an even number, take the aver- 
age of two consecutive moving averages to let the estimate centered on the time period. 
Step 2. Estimate Seasonal Factors. 

Divide the actual demand by the centered moving average to obtain the estimate seasonal factor. Dampen the ran- 
is dom effects by taking averages for similar periods in different years. Then, normalize the estimate seasonal factors 
that totals to P. Using the normalized seasonal factors remove the seasonality effects from the demand data. 
Step 3. Estimate Level and Trend Terms. 

Using the regression equation algorithm specified elsewhere herein, find the regression parameters for level and 
trend coefficients to fit the regression Gna Using the regression coefficients remove the trend effects from the 
20 demand data. 

After an appropriate time series model has been selected for afl non-promotion periods, one can interpolate the so- 
called base-line sales volumes in the promotion periods which would have arisen in the absence of the special promo- 
tion activities. By calculating the ratios of the actual sales volumes during the promotion periods and the calculated 

23 "base One" values, one constructs an impact-curve as in figure 31 for each promotion period separately. The impact 
curves pertaining to different promotion periods of a given type can next be aggregated into a single curve using stand- 
ard curve fating techniques, see figure 32. The resulting impact factors for each of the periods belonging to and follow- 
ing after a promotion interval can now be used in future forecasting efforts, as guided by our Forecasting Module. This 
approach follows that of Abraham and Lodish (1992) who have successfully adopted the methodologies in their earlier 

30 PROMOTER system to analyze retailer promotions. The PROMOTER model has four primary steps: (1) adjustment of 
the data for trend, seasonality. (2) elimination of data points influenced by promotion. (3) extrapolation of data points not 
influenced by promotion into promotion period, and (4) computation of promotion effect as the difference between this 
baseline and actual sales. 
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MODEL 


" WHfcR^ USED 


Qhat*ig^iral forecAAtina models* 

• movi.nci Ave x° acre 

• trend 

• smoothing models 

• Holt Winters model 

• Winter's method 

• Reareaaion based 
forecasting 

• Autoregressive / 
Moving average models 


Demand PHaraefcerixa^ATi?^" \ 

Bottom-iiD Forecast 
Top-down Forecast 
VMR 


Expert based tore casting model: 


Bottom-up Forecast 


seasonal icy lactors eatiiodtion 
routine 


HonanH Pliai^a^^^vi vaM Sri 
UcfllauU UiataCUgilZaulOIi 

Bottom-up Forecast 
Top-down Forecast 
PSI 
VMR 


Forecast accuracy routines: 

• Forecast error 
calculation 

• Exception report 
generation 


Bottom-up Forecast 
Top-down Forecast 
PSI 
VMR 


Past promotions impact 
estimation model: 

• Regression model 

• Time series model 


sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 


Future promotion impact 
estimation model 


Sales Promotion Analysis 
Bottom-up Forecast 
Top-down Forecast 



Table 10 
Usage of SFP Models 



Models Specific to Repair Environment 
Definitions 



Equipment consists of modules that are composed of reparable items, and repairable items are made of compo- 
nents. 

Requirement: failure of an equipment 

Consolidation policy: the policy of replacing the defective reparable item of a failed module with a good reparable item 

45 of an already defective module and reinstalling into the equipment 

Defective ratio: ratio of number of defective reparable item to the total number of reparable items in a module. 
Target level: maximum defective ratio acceptable before a module can be sent back from the equipment location to the 
repair depot The target level is one of the two parameters of the consolidation policy. 

Raw requirements (praconsofidation requirements): total requirements generated by all equipment at the equipment 
so location 

Consolidated requirements (post-consolidation requirements): requirements tor equipment after consolidation policy is 
applied to raw equipment requirements (number of modules sent to repair depot for repair from the equipment location) 
Raw Requirements Estimation (for Bottom-up estimation) 

55 Objective 

To estimate raw requirements for aO equipment located at a particular equipment location based on the planned 
activity (usage) schedules of the equipment 
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Input 

Equipment located at the equipment location. 

Activity schedules for all the equipment at the equipment location such as: 

5 

equipment upgradeAnaintenance schedules (preventive and breakdown maintenance schedules) 
activities (i.a, operation time, number of setups, cumulative operation time) 
planned activity schedules for all equipment at the equipment location 

10 Output 

Estimations of the raw requirements for each equipment at the equipment location 
Algorithmic steps 

t$ 

Establish relationships between raw requirements and activities of the equipment based on analysis of graphs, etc. 
Analyze the effects of activities on requirements using regression or time-series models 

Estimate raw requirements for each equipment given the equipment's planned activity schedule by the models used 
above. 

20 Consolidated Requirements Estimation (for Bottom-up estimation) 
Objective 

To estimate consolidated requirements for all equipment located at an equipment location based on the estimated 
25 raw requirements 

Input 

Estimated raw requirements for each equipment at the equipment location and the time of requirement 
30 Batching parameter for the batching policy of the equipment location 
Consolidation policy (target level and the search rule) 
Inventory positions at the equipment location for modules and reparable items 

Performance measures: stock level, service level (availability of equipment), repair cost associated with repair at 
equipment locations and the repair depot 

35 

Output 

Estimates of consolidated requirements for all equipment at an equipment location 

Values of performance measures 

Algorithmic steps 

Search under consolidation policy 
Identify repairable items to be sent to repair depot under batching policy of the equipment location 

Consolidation Policy 

A consolidation policy consists of two elements: a search rule for selecting the defective repairable item to be con- 
solidated, and a target level, that is the maximum defective ratio acceptable before a module can be sent back from the 
so equipment location to the repair depot 

Given a newly failed module of type I with a defective reparable item of type j. the consolidation policy defines which 
reparable item should be chosen out of which module to perform the consolidation. The chosen repairable item should 
already be part of a module with at least one defective reparable item but containing a good component of type j. The 
search rule select the reparable item for consolidation among all such defective modules. The following search odes are 
55 considered: 

Carry out the search for defective modules of type I only. Sort the defective modules of type I in decreasing order 
of the defective ratio and starting from the top of the fist, select the first module that has a good component j in it if one 
exists If not. sort aD the other defective modules in decreasing order of the defective ratio and starting from the top of 
the lid. select the first module that has a good reparable item j in it, if one exists. If not. (consolidation cannot take place) 
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replace the fefled module I with a good one, if one is available at the equipment location, tf net equipment becomes 
unavailable untfl either a consolidation or a replacement can be mada 

Oetermine afl module types for which stocks of good items at the equipment location are below a threshold value. 
Sort the defective modules of all such types in decreasing order of the defective ratio and starting from the top of the 
list, select the first module that has a good reparable item j, if one exists. If not sort afl the other defective modules in 
decreasing order of the defective ratio and starting from the top of the Cst select the first module that has a good repa* 
rafale item j, if one exists, rf not (consolidation cannot take place) replace the failed module of type I with a good module 
of type I if a good one is available at the equipment location. H not the equipment becomes unavailable until ether a 
consolidation or a replacement can be mada 

Sort the defective modules of all types in decreasing aider of the defective ratio and starting from the top of the fet 
select the first module that has a good reparable item j in ft, if one exists. If not (consolidation cannot take place) replace 
the failed module of type I with a good one, rf one is available at the equipment location. If not equipment becomes una- 
vailable until either a consolidation or a replacement can be mada 

Batching Policy 

The batching poGcy is defined by the size of a batch, TTH1, (TH1 can be equal to 1). The inventory policy is in the 
form of. count the number of defective modules with defective ratio greater than the target level. If this number is greater 
than TH 1 , then send TH1 units of repairable items to the repair shop else wait until this condition is satisfied. 

Consolidated Requirements Estimation (for Top-down estimation) 

Objective 

To estimate consolidated requirements for all equipment located at a particular equipment location based on his- 
torical data 

Input 

Tune series of consolidated requirements for each equipment locations 
Output 

Estimates of consolidated requirements for all equipment at an equipment location 
Algorithmic steps 

Use a conventional Kalman filter based algorithm and conventional statistical forecasting methods to estimate con- 
solidated requirement tar the equipment 



Determining a repair plan 
Objective 

To determine a repair pfan based on aggregate repair plan, and repair constraints (resource capacities and key. 

component availability) 

Input 

Aggregate repair plan 

Available resource capacities and degree of flexibility to change resource capacities 

Key component availability (projected inventory positions, supplier and lead time information, inventory replenish- 
ment policy) 

Output 

Repair plan for the repair shop that is feasible with respect to the repair constraints (capacity and key component 
availability). 
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Finished Goods Inventory Management (FG1M) 164 
Scope and objective 

5 Objective: Decide where to stock, how much and when to replenish in (hybrid) rnade-to-stoc*Miade-to-order envi- 
ronment 

Scope: Single and dual echelon. 
Features: 

Single and dual echelon inventory models tor how much and when to replenish stocking points. Cost vs. service trade 
10 offsto determine where to stock 
Deployment 

Models specific to manufacturing environment 
Overview 

15 

Objectives 

This module contains a collection of finished goods' inventory models enabling the selection and evaluation of 
inventory policies. The module returns an I* and P- One extended to a given horizon (of T periods) beyond the current 
20 period. At this stage, afl of the models represent settings where any given item is dstrfouted to the customers from a 
single location. 

Input 

25 Forecasts of mean demands per item, per period (S v line); standard deviations of demands per period per item (& 
line); mean production lead times for each period per item (V line); standard deviations of lead times far each period, 
per item (t* line). 

Output 

30 

Inventory (I) One 
Production (P 1 ) line 
Inventory strategies 

Models are classified as follows: Ml. Models with Non-Lumpy Demand; and Mil. Models with Lumpy Demand. Lumpy 
$5 demands refers to settings where demands are sporadic or experience extreme variability. The demand process for a 
given item will be classified as lumpy if the percentage of zero demand periods or the coefficient of variation of the 
demands is above pre-specH ied critical levels. 

Within the category Ml we next differentiate between: MI.1 Models managing inventories or on an item-by-item 

basis; and MI.2 Multi-item models with join t capacity constraint s. 

ao The choice between these two categories depends on whether or not important interdependendes prevail between 
the items (in the form of joint capacity constraints or joint cost structures). Within each of the subcategories MM and 
ML2, different models can be selected based on the extent to which policy parameters are to be pre-spedfied by the 
user or computed based on an appropriate tradeoff between cost and service measures. 

- 45- Ml Inventory Models for^tor^Uir^py Demand 

MI.1 Models tor Independent Items 

As mentioned above, in this category inventories are managed on an item-by-item basis. Different models need to 
so be invoked dependent upon the extent to which policy parameters are to be specified by the user. Alternatively, the 
models to be used can be determined endogenously based on an appropriate tradeoff analysis or optimization of vari- 
ous cost and service measures. 

Ml. 1.1 User-Specified Base-Stock Policies 

55 

Objective 

In this model, the user specifies an order-up-to or base-stock level as a given number of weeks of inventory. Based 
on this inventory policy, the model projects out an I* and P* One tor a scenario in which the forecasted mean demands 



57 



EP 0770 967 A2 

are realized. 

Additional Inputs 

s The desired base-stock level for each period 

r\ » number of periods of future forecasted demands in which the inventory position rs to be increased at the begin- 
ning of periods if below 

io Algorithm 

Step 1 : Compute b, « S, + S^ +.. .+ (If n, is specified as a fractional value, bf equals: 
b, - S, ♦ S^,*...* S nlJ ♦ (nt - IaD %nn> 
Step 2: Project V and P fine Let: 

15 

^ n inventory position (inventory level plus outstanding orders) before ordering at beginning of period 1. 
Pj » prod uct ion volume ordered at beginning of period t 

Set Pi =b| -l 0 ; project recursively fort « 1 T-1: 

20 

^-max^lJ + PfS, 
Pi»i-n«(h»i-fc»i;<9 

Step 3: Evaluation of various service and cost measures, 

23 

a) eg., expected average inventory level, 

b) probability of stock-out 

c) f 31 rate or percentage of demands satisfied from stock 

d) number of setups. 

so e) average backlog sizes. 

Ml. 1.2 MIN-MAX Policies Based on Optimization of Aggregate Cost Measures 
Objective 

33 

In this model, a policy is computed which minimizes the expected value of the aggregate of all relevant cost com- 
ponents, i.e. 1) setup costs: 2) inventory carrying costs: and 3) bacMogging costs. The model is appropriate in settings 
where stock-outs are fully baddogged and where the inventory carrying and bacMogging costs are proportional with the 
inventory levels and backlog sizes. 

40 

Additional inputs: 

Holding cost rates per item per period (h* tine) 
BacMogging cost rate per items per period (p* line) 
45 variable production castrate per item per period (c' line) 

Algorithm 

Step 1: Load S* (Sales). & (Standard deviation), V (Lead times), x' (Standard deviations of lead times). K (setup 
so costs), h' (Holding cost rates).' p* (bacMogging cost rates). C (variable production cost rates): 
Step 2: Rt appropriate demand distribution to S\ & Ones, 
fit appropriate lead time distributions to V and V lines. 

Step 3: Serve for time-phased optimal (s,Q) policy. Such a policy has for each period t =» 1 T. two critical levels s, 

and Q| such that whenever beginning inventory position \ t <s t an order is placed for (6,+Q, - IJ units. Parameters (s,, 
55 Q|) are computed from the following recursion. 
Let 

V^l) a expected minimum costs in periods 1 1+1 T given that period t starts with an inventory position of I 

units. 
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Gfy) - expected finventory carrying and baddogging) costs associated with period t (This function uses the 
lead time and denrand distributions computed in Step 2 as well as the h' andp' lines) 
D t a demand in period t 

Solve: 

Note: the user is provided with the option to specify ranges for the production quantities x^ t ....jc T . These ranges 
may reflect capacity limits per item, or flexfoffity limits in view of prior determined P' and V Ones. The ranges wfll be 
used to restrict the choice of x. 
Output: 

ForaDta 1 T; 

Xt*(i) 3 optimal order quantity at the beginning of period t when inventory position = I. 
Step 4: Create Y and P lines. 

I, is known: set P t = production lot initiated in period 1 equal to X # t (I). Then project recursively tor t = 1 T 

Step 5: Evaluation of various cost and service measures, as in Step 2 of model M1.1. 
MM. 3 Periodic Review Models Under Service Level 
Constraints 
Objective 

In this category of models the inventory policy minimizes expected setup and holding costs subject to user speci- 
fied service level constraints. The user may choose between the two types of conventional service measures. 

Type 1 Service Constraints: 

Maximum permitted probability of a stock-out during lead-time following potential order at beginning of a given 
period. Let: 

— op maximum permitted likelihood of stock-out during lead-time following potential order at beginning of period 

L 

Type 2 Service Constraints: 

Minimum acceptable fill rate during lead time tallowing a potential order at beginning of period. Fill rate is defined 

45 ?s the percentage of demand sati sfied from stock. - 

Let 

p P minimum acceptable fill rate during lead time following a potential order at beginning of period t. 

The model is based on the same assumptions as MM except that stock-out frequencies are controlled via service 
level constraints (of Type 1 or Type 2) as apposed to explicit stock-out or bacMogging costs. 

Additional Inputs 

holding cost rates per item per period <h' line) 

maximum permitted stock-out probabilities per Hern per period (a* line), or minimum acceptable fill rates per item 
per period (p' line) 
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Step 1 : Load S* (Sales). & (standard delations). L* (lead-times), IC (setup costs), hr (holding cost rates), cf (variable 
production cost rates), a (service level type 1) or p* (service level type 2). (Lead-times are specified either as con- 
s starts or via ranges with associated likelihood tor each value in the range) 

Step 2: Fit appropriate demand distribution to S\ a' lines. Determine lead time demand cGstrfcutior* 
Let 

LD t o lead time demand for order placed at beginning of period t tf lead time demand distribution is chosen to 
to be Normal (for example), then set its mean and variance as follows: 



15 



Step 3: Compute minimum inventory positions after ordering S, , via Reorder Point Algorithm, below: 
Step 4: Solve for time-phased optimal (s,Q) policy. 
25 Let 

V, (I) a expected minimum costs in periods 1 1+1 T given that period t starts with an inventory position of I 

units. 

Qfy) a expected inventory carrying and baddogging costs associated with period t 
30 Dt - demand in period t 

Solve: 

i 

V e (I) -«Se-J { [*« i i / J £ 0 °]*C e X*<?<.r*x) *Ev t ^ ( I+x-D t ) 

t « 1, - . . ,T; all I 



40 ~ Output: ' " " " " ^ - - - ■ 

for all to 1 T: 

x*, (I) o optimal order quantity at the beginning of period t. when inventory position o l. 

45 Note: the user is provided with the option to specify ranges for the production quantities x,. % t X T These ranges 

may reflect capacity limits per item, or flexibility Gmits in view of prior determined P and r lines. The ranges will be 
used to restrict the choice of x in (2). 
Step 4: Create r and P lines. 

I, is Known; set Pi = production lot initiated in period 1 equal to x* t (I). Then project recursively for t » 1 T 

50 

Step 5: Evaluation of various cost and service measures, as in Step 2 of model M1.1. 

55 
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ML2 Mufti-item Capacitated Periodic Review Models with Service Level Constraints 
Objective 

5 This category of models plans simultaneously tor a complete family of items incorporating various joint capacity 
constraints. The model plans production quantities on the basis of estimated mean demands; however, minimum inven- 
tory levels are specified to satisfy user specified service constraints (of Type 1 or Type 2, see MM .3. above). The P* and 
r One are in this case determined by the solution of an LP -model. The user specifies whether minimum inventory levels 
are to be determined on the basis of Type 1 or Type 2 constraints In addition, the user chooses among a number of 

10 possible objective functions (performance measures) to select among feasfcle plans. 

LP formulation 
Model: 

15 

LP formulation for I products (or product group) K resources (Key Component and/or Lines) sets and T periods 
Input 

20 % » Demand for product i at period t 

Sft » Minimum amount of product i at the end of period t 

Is a Initial inventory of product i at the beginning of the planning horiron 

amj « Units of resource m, among resources in set S* required per unit production/repair of product i 
c^ ■ Units of resource m which becomes available at period t (In case resource m is a key component, is the 
25 amount of it available at the beginning of the horizon under consideration.) 

Oecision Variables: 

P it a Units of product i to produce in period t 
30 Xmi, « Units of product i to produce in period t using resource m in 
I* a Inventory of product i at the end of period t LP (A) Optimize: 
OV1 . OV2, OV3 or OV4 specified below: 
subject to 

35 Iit-i + Pit-*it oI ic for i 9 1.2,..., I and t « 1,2,...,T (1) 

r a u skX^t-Pu for Jc = 1,2, . . . ,K, i«l,2, . . . ,1 and 

t » 1,2, . . .,T (2) 

- - - cZi-a^x^ -?.o_ to. t c M _ .__Jgr each ke y component m an d 

t = 1,2. .,T (2.1) 

E l a mlX|ilt< aC IBt f°r each line resource m and 

t - 1,2, ...,T (2.2) 

45 i lt as lt _ for iol,2,...,I and t a l,2,...,T (3) 

x^aO for m in S k , k=l,2,...,K, i=l , 2, . . . , I and 

t - 1,2, ...,T (4) 

50 

Constraints: 

calculate the inventory levels, 
55 (2. 1 ) and (2.2) ensure that consumption does not exceed resource availability. 

ensure inventory is no less than pre-specHied levels and ensure that production/repair is non-negative. 
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Output: 

Feasibility of LP 

5 H yes, a production plan : P& tor i <> 1 A... J and t - 1,2.... J the corresponding inventory levels : fj, for i - 1 2 1 and 

t - 1 ,2 T and remaining resources : slacks in (2.1) and (2.2). 

If no, display sources of infeasfoffity : surpluses in (2.1) and (2.2). 

OV1 : Maximize maximum slack in resource constraints (2.1) and (2.2) 
10 OV2: (Balance Workload). 
n*n I [a^WCnrt J 

OV3: Minimize variable production and hokfing costs 
rwnllCHPtt + hhliJ 

OV4: Minimize maximum inventory in weeks 
is minmaXftllj/Srt] 

Algorithm 

Step 1 : Load S* (sales). & (standard deviations). V (lead times), h' (holding cost rates). € (variable production cost 
so rates). x v (standard deviations of lead times); resource utilization matrix [a^ capacity levels [C m J. 
Step 2: Determine lead time distributions LD t , as in Step 2 of Ml. 1.3. 

Step 3: Compute minimum inventory positions after ordering s 1 r\&r via Reorder Point Algorithm. 

Step 4: Solve above LP. 

Step 5: Identical to Step 5 of model Ml 1 . 1 . 

25 

M II. Inventory Models tor Lunpy Demand 

Apply to lumpy demand. The tunpiness of demand is measured as proposed herein. 
30 M 3. 1 Maximum Demand during Period YT Policy 
Objective 

This policy is suitable tor low cost slow moving items with lumpy demand. 

33 

Inputs 

S* line, cover period a 

40— Outputs 

MAX level, inventory target. 
Frames using these models include 
PSI Planning Frame 160 (CF8) 
45 VMR Frame 250 (CF19 and€F20) 



Algorithm 

Step 1. Use method 1 to categorize lumpy demand 
so Step 2. Determine W; a worst case scenario would be to set W as the replenishment lead-time. 

Step 3. Determine the maximum demand during period W and set it as the inventory target, MAX. 

Step 4. Compute I 1 line: 

to-i+Vto 9 to tor I s 1 J ^ ! 3 1 2 * T 

55 M 32 Expected Deficit MIN-MAX 
Objective 

This poficy is suitable in cases where there are fairly expensive items that have lumpy demand. 
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Inputs 
ffOne 
5 Outputs 



Max level, inventory target 
Frame using the model includes 
PSI Planning Frame 160 

Algorithm 



10 



30 



35 



Sad «ft* (average period sa.es) as one*a» of the beginn*g and endng .uantty 

«!« *i AwkWOfl^as the ROP quantity plus the «der quantity less the expected detet 

J ^^ZvX"^ point the difference between the targeted quantity MAX and 

the quantity-on-hand fs ordered. 
Compute the r line: 

\u+*p<tfi o Ijtfer j « 1.2 J and t » 1 A~T 



inventory models *pr 
items with non-lumpy demand: 

• User specified base-stocK 
policies 

• Min-max policies based on 
optimization of aggregate 
cost measures 

• Periodic review models 
under service level 

constraints 

inventory models tor multi-item wit 

non - lumpy demand : 

• Capacitated periodic review 
model with service level 
constraints 

inventory models tor lumpy ae 

Maximum demand during 
period % n' policy 

Expected deficit min-max 

ppjicy . 



Table 11 
Usage of FGIM Models 
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Models specific to repair environment 
Determining CSI levels 
Objective 

To determine CSI level for each module type 
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Lead-times from each plant to every DC it replenishes, and the average lead-times from every DC to the stores it 
supplies. 

Planning horizon specifications 

Output 

Required inventory Ones (R' lines). 
Notation 

to • beginning period of the planning horizon (assuming that today' is the beginning of period number 1). 
T- the length of the planning horizon. 

Rt^j) - required inventory level, of product j at DC I. at the beginning of period t when delivery frequency f is 
applied. 

og - required service level for product j at DC I. 

^ - mean demand for product j at DC I during period i 

o 1 -- standard deviation of the demand for product j at DC I during period t 

b\ • demand dispersion rate for product j at DC I. The dispersion rate is defined as follows: 

(R - 1> d„ A(£a e «')/0 c ", 

* r««eox««<i> 

and is assumed to be constant over time, stores (I) denotes the set of stores replenished by DC I. Note that we do 
not require the data afy which represents standard deviation of demands at individual stores. The parameters 6^8 
can be calculated (or even roughly estimated) by an observation of a set of historical stores' data 

- Lead-time from the plant that produces product j to DC I. 
Aa • Average lead-time from DC I. to its stores, for product j. 

Q - Set of 'quarters' into which the planning horizon is split Each quarter is a continuous time interval consisting of 
one or more periods. 

Q,. QJ - Quarter number q and the number of periods in it (note that ). 

F - The set of all possible delivery frequencies. Each delivery frequency f is specified as the minimal number of peri- 
ods between two consecutive delivery periods. The values f must be integral (for non-integral values, redefine the 
base period, e.g. half a week instead of a week). 

utym). o" 5 (m) • The mean and standard deviation of the demand for product j at all stores supplied by DC I. over 
periods t until t+L^t+m (nrttO is a parameter of these functions). The term t+Lg++m represents the expected time at 
which a delivery shipped from the plant at period t+m (next possible delivery time), arrives to the stores. 

Algorithm Steps 



For all product-DC couples (i, j) 
For all frequencies f in F 
time>0 

For all 'quarters' q in Q 

Fbraflperiodstal toQ^J: 

time := time + 1 

// compute the time to next feasible delivery period. 
t_del.// 

t.deJ :=f-l(Uf-1)modfl 
timeJo.DC :» tjdel ♦ Lq 
timejo_stores :* timejo_DC ♦ ^ 
compute the values 
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(R.2) 



and 



(R.3) 

og- C t del) « £ <>V*iJ £ 

for a part of a period use the following interpolation method: Let X be the period number and let 0 < a < 1 be the fraction 
of that period. Then, 
(R.4)mean = a • f 

(R.5) Std - 



Use (R5) if the demand in this part of the period « assumed to be independent of the demand during the rest of the 
period. Another way to calculate the standard deviation can be. far instance. 

The inventory requirement tor period time is now computed via 
(R.6) 

(if j) -(I If ( tjiel) ( 1 -«^) d-gT ( tjiel ) 



_ End For (t) 

End For (q) 
End For (f) 
End For (IJ) 

Estimate Stock-out Probability tor a Given Replenishment 
Quantity: Model (OR1): 



Objective 

For a given replenishment quantity of product j, delivered from plant p© to DC I. this model estimates the expected 
projected stock-out probability. The stock-out probability is defined as the probability of shortage in at least one of the 
stores replenished by the DC The word -projected" refers to lead-time periods later, when goods are expected to reach 
the stores. 

Notation 

In addition to the notation defined up to this point we define: 

DEKJV - delivery size, 
date -date of delivery. 
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arr * (expected) arrival date of goods to stores 

Xf** - the echelon inventory level of product! in OC I, at (period) time data 

Algorithm Steps 

Use formula (&2), with tjdeM , to calculate the expected demand over the lead-time, 



(1). Simaarty calculate the standard deviation of this demand. 



(1), via formula (R.3) (again, by setting t_deM). 

The projected stock-out probability can be approximated by: 



(OR.l) 



In certain situations the user may be interested in Knowing the projected service levels for periods further than arr. Such 
interest may arise when no deliveries are planned for subsequent (number of) period(s). To evaluate the projected 

stock-out probability at period arr+K when no deliveries are to be made during the following k periods (i.e. date+1 

date+fc), use the formula: 



(OR. 2) 



ij [ d?;"(i*ic) J 



Strategic Model: VMR Contract Setup © 
^"Objective ~ " " 

This module consists of a set of models tailored to support replenishment planning by integrating: (1) service level 
requirements; (2) limits on customers* inventory investments; (3) transportation costs; and (4) delivery frequency. 

— 45— Input * 

Below is the input which is common to all of the models described in this particular discussion: 
Network Structure. 
Demand Forecast 

so Lead-times from each Plant to each DC and (an average) from each DC to its Stores. 

Planning Horizon Specifications 

Current Inventory Positions. 

Transportation Cost Structure and Trucks Volumes. 

Products' Volumes (for Transportation Cost Calculations). 
55 Computing The Optimal Delivery Frequencies: Model (C1) 

Objective 

This model computes delivery frequencies from each plant to the DC it replenishes such as to minimize total trans- 
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portation costs. The delivery frequencies are set such that given requirements on service levels are satisfied and such 
that constraints on average inventories are not violated. 

Input: 

Inventory Requirements (R* Line, see Model R). 
Set of PossMe Delivery Frequencies. 
Required Service Levels (in Terms of Stock-out Probabilities), 
Limits on Maximal Inventory Investments (in terms of Weeks of Demand). 

Output 

Delivery Frequencies. 
Estimated Level of Service. 
Estimated Transportation Costs, 
Estimated Inventory Levels. 

Notation 

We use the same notation as in Model R (except for the notation for defivery frequencies) plus the following: 
Indices 

I - DC Index 

j - product (module) index 
p- plant index 
f • delivery frequency index 

s - index of One segment of transportation cost function (the cost structure is approximated by a piece-wise linear 
function) 
t-time index 
q. quarter index 0 

Sets 

I • set of afl DCs 
J - set of ail products 
P- set of ail plants 

F - set of possible delivery frequencies 
J 1 • afl products sold to DC i. 

40 J p - afl products produced in plant p. — 

Transportation cost parameters (for deliveries from plant p to DC I) 
vol,, - total volume of a single truck 

C p : cost of fujj truck load -( FTL) 

fbt^ - fixed cost of less than full truck load (LTL) 

Tjp it - (right) end point of the s-th line segment (La. [x^i . i&s] ) of the LTL cost function, 
rateip, - transportation cost rate for volumes in segment s (i.e.. in between and t^J. for LTL shipments, 
vj • volume of product j (for cost calculation purpose) * upper emit on the average number of weeks of inventory in 
DC I in quarter^ ~ 

Decision variables 

X*,) - echelon inventory of product j at DC I (including outstanding orders) in the beginning of period t 
S\ - delivery quantity of product j to DC I in period t. 

F%rf • an indicator set to 1 if in quarter q a delivery frequency f is followed for the replenishment of DC I by plant p. 
Otherwise it is set to zero. 

NFfjp - number of fufl-truck-toad sent to DC I from plant p during period 1 
LTL'ip- volume of LTL (zero if none) shipment sent to DC I from plant p during period t 
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Yt^ - total vdume of LTL shipm ent that fans into One segm ertt (cost rate category) nuntoer s. Note that . 
Z*^,- an indicator set to 1 if the LTL shipment size is larger than ; La, segment 6 is partially or entirely cov- 
ered. Note that Z 1 ^ Is always less or equal to Z 1 ^, . 

5 Algorithm Steps 

The following Mixed-Integer Linear Programming problem is solved: 
Problem (C1): 



10 



ST. 

is Initialize inventory positions: 
(01-1) 



X, 1 ^ 1 i.j 



20 System dynamics: (expected) beginning DC echelon inventory ° (expected) beginning inventory of last period + deliv- 
ery quantity to the DC during the last period -expected demand in the last period: 
(C1.2) 

X | , «X | M *8, l " , -|i | M ij.t>1 

23 ' 

Beginning (expected) inventory level needs to satisfy the requirement constraint, for the relevant frequency level: 
(CI. 3) 

30 */ ( i . j) F f p/ ; ceO^c J p i.p.q 

Only one frequency is chosen for each triple (DC, product and quarter): 

38 

(CI. 4) 



Average echelon inventory (across all products) should not exceed a given level. This level is given in terms of weeks 
of inventory. Note that we subtract one half since X is the beginning inventory level (white we are interested in average 
over the period, i.e. X-p/2): 

45 — 



(CI. 5) 



Upper bound on the number of full truck loads (FTL): 



55 
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(CI. 6) 



i.P.t. 



Lower bound on the number of FTLs: 
(CI. 7) 



i,p,t 



Deliveries not send by the FTLs are sent by LTL 
(CI. 8) 

Setting the transportation cost constraints (See 4.8.1): 
(CX. 9) 



i,p,t 



(crrio) ; 

(*ip,** T ip,#-i) 'Zip.fltYip.s*^ ip,«~ T ip,«-i) * Z iP.i 

i,p,t,3 

(Cl~ 11) ~ ~~ 

Zip.**Zip.9»i 

i,p,t,s 

(CI. 12) 

Zip.^O.X) 

i,p,t.s 



Integrality constraints 
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10 



15 



20 



(CI. 14) 

i,p,q,f 

(CI. 15) 

NFTfeln tegexs 

i.P.t 

To estimate the operating parameters, described above as part of the output of this model use Mode* (C4) (described 
later). 

Computing Maximal Average Levels of Service: Model (C2) Objective: Given the delivery frequencies and Omits on the 
average number of weeks of (echelon) inventories, this model calculates the maxima) average service level that can be 
obtained. 

Input 



Inventory Requirements (FT Line, see Model R) 
Delivery Frequencies 

29 Limits on Maxima) Inventory Investments (in terms of Weeks of Demand) 

Output 

Estimated Level of Service 

30 Estimated Transportation Costs 
Estimated Inventory Levels 

Notation 

as We use the same notation as in Model C1 plus the following: 

- -projected- (i.e. lead-time" periods after period t) level of service for product j in DC I at period t. 
1^ ■ a given set of periods in which replenishment (from plant p to DC I) is permitted. 
Wjj • values of objective coefficients (see discussion later) 

40 



Algorithm Steps: The following problem is of interest 
i(C2): 



qtQ Ul CtQfjcj * 



ST. 

(C&1HC1.1) 

50 (C22)(C1.2) 
(C2.3)(C1.5) 

Formula used to approximate the "projected" level of service (see Model (OR1): 
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i, j.t 



i.j.t 



20 Note that Problem (C2) is separable both in I and in q. In addition, in order to deal with the non-linear constraint (C2.4) 
we approximate the Standard-Normal cumulative distribution function (<X>) by a piece-wise linear function (with m seg- 
ments); tor further details, see below. 

As in Model (C1), we define for the piece-wise linear function the parameters and variables (for further details, see 
below): 

m - number of "segments" in the piece-wise linear function. 

a, - the s-th breakpoint of the piece-wise linear function (s=0,....m); i.a the s-th segment is given by (6^ , ]. 
d, - the slope of the s-th segment of the piece-wise linear function (s-1 ,...,m). 
2j A - the binary variables associated with this transformation. 
30 Yy, - the continuous variable associated with this transformation. 

In the following problems we use and Y^, with respect to 



see below. 
Problem (C2)V 



43 ST. ■ - 

(C2\T) T(C1.1) only for the relevant value of i and teQq 
(C2\2) (C1.2) only for the relevant value of i and teC^ 
(C2*.3) (CL5) (single constraint) 
See the discussion herein for details on (C2\4)-(C2\8): 

50 



(C2.4) 



10 

No delivery can be made in periods that are not compliant with the given delivery frequencies 
(C2.5) 

» s£=0 fox all c*T ip 
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10 



is 



30 



(C2'.4) 



(C2' .5) 



<C2' .6) 



(C2' .7) 



(C2' .8) 



j.t 



(6,-8,.,) (8,-8.-»> */• 

j.t.a 



j ,t, »■!» . . . ,ra-l 



j.t.s 



„ (C2' 9) (C2.S) only for ftaielevant va lue of I - 

Remarto 

The weights wjj should be set such that 

E £ «s«-i 

55 . To determine the appropriate weights one should consider the relevant factors that need to be taken into account (e.g. 
priorities, demand volumes, etc.) 

In case that some products have low service levels, the problem can be resolved with the addition of the following con- 
straint 
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(C2' .10) 



where 93 are prespebfied lower bounds on the level of service. Another option, which does not require the specification 
of^fe 

(C2' .XI) 



wHhiurt- 

Minimizing Average OC Echelon Inventory Levels: Model (C3) 

Objective: Given the delivery frequencies and required service levels, this model computes the minimal average 
number of weeks of inventories at each one of the OCs in every quarter. 

Input 

Inventory Requirements (FT Line, see Model R) 
Delivery Frequencies 

Required Service Levels (in Terms of Stock-out Probabilities) 

Output 

Estimated Level of Service 
Estimated Transportation Costs 
Estimated Inventory Levels 



Notation 

We use the same notation as in Model C2 plus the following: 

1 p(j)-- the plant in whidi product] is produced, -~_ 

q(t) - the quarter to which period t belongs. 

R*(i.D - this is the inventory requirement as defined tor Model R, but without the subscript f. It now refers to the given 
delivery frequency from plant p(j) to DC I in quarter q(t). 

AVQ 1 ! - the average echelon inventory level in terms of weeks of demand (tor DC I in quarter q). 

> 

Algorithm Steps 

for each DC I in I: 

r Step 1: For each product j, je J 1 : 
Solve the foDowing problem: 
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S.Z 

(Cai)(C1.1) (single constraint) 
(C3.2)(C12) 

10 Beginning inventories must satisfy minimal requirements: 



15 



20 



(C3.3) 



End For ffl 
Step 2:ForeachqinQ 
Calculate the value 

(C3.4) 



35 End For (q) End For (0 

Computation of Operating Parameters: Model (C4) 

Objective 

40 

Given a delivery plan (La the values Sty. this model computes the following operating values: (1) estimated inven- 
tory levels. (2) estimated levels of service, and (3) estimated transportation costs. 

Input 

' Delivery Plan (Sty. 
Output 

so Estimated Level of Service 

Estimated Transportation Costs 
Estimated Inventory Levels 

Notation 

55 

P* - Set of all plants that replenish DC I. 
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Algorithm Steps 
For each OClin I: 

5 Step 1: Evaluate the expected (echelon) inventory positions at the beginning of each period via the equations 
(C1.1).(C1.2) 

Step 2: For each quarter q in Q 

2.1 Evaluate the value AVG'i via (C3.4) 
10 22 Evaluate the expected levels of service 0 via (C2.4). 

2.3 Evaluate total transportation costs over the quarter (can be done by an external procedure) for each plant . 

End For (q) 

is Check Compatibility of a Given Set of Constraints: Model (C5) 
Objective 

This model checks whether a set of constrains (service levels, maximal echelon inventory levels and delivery fre- 
20 quendes) is compatible or not 

Input 

Inventory Requirements (fV Line, see Model R) 
25 Set of Possible Delivery Frequencies 

Required Service Levels fin Terms of Stock-out Probabilities) 

Limits on Maximal Inventory IrTvestrnents (in terms of Weeks of Demand) 

Output 

30 

FeasibiBty(YesorNo) 
Algorithm Steps 
35 For each I in I: 

Step 1: For each plant pcP: 

Select the most frequent among the feasible delivery frequencies from plant p to DC I (this represent the less 
restrictive constraint). 

-40 For this delivery frequency, evaluate the inventory requirements R\i J by using Model R. 

Calculate the values as in Model C4. 
End For (p) 

Step 2: For each q in Q 

. 45 Evaluate the value AVGVvia (C3.4) ^ 

Check that 

AVGfixl 

so 

is satisfied. If not STOPI the set of constraints is incompatiUa 

End For (q) 

EndFbr(l) 

55 Determine Production and Delivery Schedules: Model (C6) 
Objective 

This model suggests both production and delivery schedules which minimizes total transportation costs and (in* 
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plant) inventory holding costs. The plan is determined under service level constraints and constraints on average inven- 
tories at the OC (echelon) levels. 

Input 

5 

Inventory Requirements (R* Line, see Model R) 

Set off Possible Delivery Frequencies 

Required Service Levels (in Terms of Stock-out Probabilities) 

Limits on Maximal Inventory Investments fin terms of Weeks of Demand) 

to 

Output 

Delivery Frequencies 
Estimated Level off Service 
15 Estimated Transportation Costs 
Estimated Inventory Levels 
Estimated In-Plant Inventory Costs 
Proposed Production Plan 

20 Notation 

We use the same notation defined tp to this point plus the following: 
Parameters 

25 

h . holding cost for unit of product j (in plant pffl). per period. 

inv'j - inventory of product j in plant (pffl) at the beginning of the planning horizon. 

M - "big- number (see (C6.5)). 

30 Sets 

IQ) • set off all DCs that carry product j. 
Decision variables 

35 

PROD 1 } - production batch size off product j in period t 

INV} - inventory off product j in plant pffl at the beginning off period t 

Algorithm Steps 

40 — . 

The following Mixed-Integer Linear Programming problem is solved: 
Problem (C6): 




so ST. 

(C6.1)(C1.1) 
(C6.2)(C1.2) 

Initialize levels off in-piant inventories: 

55 
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(C6.3) 



to 

Inventory dynamics 

beginning inventory => last period beginning inventory + production quantity in the last period • goods delivered during 
the last period: 

,5 (C6.4) 

20 

25 Delivery can be made only if period t is consistent with the chosen delivery frequency: 
(C6.5) 



i,j,t 



35 

(C6.6)(C1.4) 
See(C1.3): 

(C6.7) 

- 40 



Jfjj*g*/ (i . J) 'Ff pf ; teQ, j€J p 



(C6.8)(C1.5) 
so (C6.9)(C1.6) 

(C6.10)(C1.7) 

(C6.11)(C10) 

(C6.12)(C1.9) 

(C6.13)(C1.10) 
55 (C6.14)(C1.11) 

(C6.15)(C1.12) 

(C6.16) (C1.14) 

(C6.17)(C1.15) 

Options for Production Capacity Constraints: 
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(C6.18) 

PRODfipzodl 

5 

to 

This set of constraints represents individual limit on production quantity tor each product in any period. 
(C6.19) 



15 




20 P,t 

This set of constraints is relevant when the different products, manufactured in a certain plant pi share critical capacity 
resources. Although (C6.19) represent a single constraint tor each plant Cm a give period t), more constraints can be 
* easily added. Note that both in (C6. 1 8) and in (C6. 1 9) lower bounds can be introduced. 

Limits on Storage Capacity 

Similarly to (C6.18) and (C6.19), analogous sets of constraints can be constructed in order to express, tor each 
30 plant: (1) limits on individual storage volumes, and (2) upper Omits on total volume (value) of storage, respectively. 

Operational Models (OP): 

Overview 

35 

In this section we describe a family of models, analogous to Models (C1)-(C3). The models are bust to assist pro- 
duction and delivery planning tor the short-term horizon. The major characteristics of these models are: 
Rolling horizon planning: production and delivery plans are made frequently (even before the end of previous planning 
horizons), thus taking into advantage updated information about demands and production capacities. 
,40— High level of details: capadty constraints are n^ smoothly 
translated into production orders. 

Flexibility in setting non-delivery periods: the user is allowed to specify periods in which delivery cannot be made. This 
replaces the requirement for following a certain delivery frequency. For instance, even if there is a certain guideline on 
delivery frequency, it can be relaxed at any (arbitrarily chosen) period. This reflects in added flexibility, which is espe- 
45 dally important in cases ef unexpected, high levels of demands (La when deliveries must be made quicWy). 

ThenunSer of constrainte (per period) is larger in th^e modelsT however, the planning horizon is usuaHy rmx^ 
shorter than that of the strategic model. In addition, since we do not need to select certain delivery frequencies there is 
no need to incorporate the integer variables F* pf This results in a significantly foster solution tima . 

so Joirt Auction-Delivery Plan: Model (OP1) - 

Description 

This model minimizes the total transportation and (inplant) inventory holding costs (see Model C6 tor more details). 

55 

Notation 

The notation here is similar to that of Model C6 with the addition of the following: 
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P&!8ffl0ttt8 

req 1 ! - requirement for echelon inventory level of product j at DC I in period t in order to maintain a certain level of 
•projected" level of service (see Model OR1 for further darffication). This minimal level depends on the delivery 
5 schedule, see Model R for explanation on how to calculate these values (very similar to the calculation of the values. 

x i - the same aa but now without the quarter index. 

to 

cap'pM - the avaflabiBty of resource k in plant p. in period t 
X l j{k) - the amount of resource k required tor a production ot unH of product j in period t 
storage ! p (k) - maximal total vciumeAraJue (etc.) of inventory remaining at the end or period t in plant p. 
15 p ! j{k) • the volume/value (etc) of unit of product j in period t 

setup^ - setup cost to initiate a production batch of product j in period t 

Sets 

20 NoDe^p - set of periods in which no delivery is allowed from plant p to DC L 

Decision variables 

P ROD ! j - production batch size of product j in period i 
25 I NV\ - inventory of product j in plant pQ) at the beginning of period i 

SETj - an integer variable indicating whether a setup is required in period t for product j. 

Algorithm Steps 

30 The following Mixed-Integer Linear Programming problem is solved: 
(OP1): 

33 

ST. 

(0P1.1)(C1.1) 
(0P1^)(C1.2) 

40- (OP1.3) (C6.3) 

(OP1.4)(C6.4) 

Deliveries can be set to zero at any period the user chooses: 
(0P1.5) 

45 . • — 



S/j^O i, j, teNoDel ipiJ) 



so Echelon inventory levels must meed certain levels: 



S3 
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(0P1.6) 



(0P1.7)(C1.5) 

(0P1.8)(C1.6) 

(OP1.9)(C1.7) 

(OP1.10)(C1.Q 
is (0P1.11)(C1.9) 

(OP1.12)(C1.10) 

(0P1.13)(C1.11) 

(0P1.U)(C1.12) 

(OP1.15)(C1.14) 
20 (OP1.16)(C1.15) 

Production capacity constraints (see ateo Model (C6)): 

(0P1-17) 



30 

Storage capacity constraints (see also Model (C6)): 
(0P1.18) 

as Pj(ic) -nrvfzstoragej (k) 



i.j,t 



p,t,)c 



p,t,k 



Introducing setup costs: 

Hie operational model can be extended so as to include setup costs (and/a setup times) as follows: 
The term 



_45_ 



_^setup/_-5£T/_ 



is added to the objective function of Model (0P1). 
so Appropriate set of constraints should be added as wett; for instance: 



55 
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(0P2 . I) 

SCT/elO.l) 

5 

(OP2.2) 

10 PRODfiti-SETj 



is This consent is pertinent if product j requires a new setup in each period it is produced. (Mis a large* number.) 

(OP2.3) 

PRODfsM' ( SETf*SET}~ 1 ) 



20 



(with SET 0 , initialized accenting to the pnxluctionyhon-production cf product j in the last period before the planning hori- 
zon). The intuitive behind this constraint is that H a product is produced in a given period, no setup is required at the 
25 subsequent period. 

Maximizing Short-Term Level of Service: Model (OP2) 
Description 

The purposed mis mri^ In the same spirit of thai model 

(C2). we change Model (OP1) as follows: 

Algorithm Steps 

35 

(OP2): 

«a*EE E 



S.T. 

(OP2.1) (OP1.1) 
(OP2.2)(OP1.2) 
-<5~ (OP2.3) (OP1 3) — 
(OP2.4)(OP1.4) 
(OP2.5)(OP1.5) 
(OP2.6) (OP1/7) 
(OP2.7)(C2\4) 
so (OP2.8) (C2\5) 

(OP2.9)(C2\6) 

(OP2.10)(C2'.7) 
(OP2.11)(C2\8) 
(OP2.12)(OP1.5) 
55 (OP2.13)(OP1.17) 
(OP2.14)(OP1.18) 
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Remarta 

Constraints (OP2.7HOP2. 11 ) use the piece-wise linear approximation to the Standard-Normal cumulative distribu- 
tion function (CDF), see beta*, 
s For explanation about the coefficients wg, see Model (C2ft. 

Note that in this case, in contrary to Model C2. the problem is not separable in I. This is due to the ca^ 
constraints (OP2.13) and (OP2.14). respectively 

Minimizing Average DC Echelon Inventory Levels: Model (OP3) 

to 

Description 

This model is analogous to the long-term model. (C3). 
We modify Model (OP1) as follows: 

15 

Algorithm Steps 

Step 1: solve the following problem: 
(OP3): 

20 




25 ST. 

(OP3.1) (OP1.1) 
(OP3.2) (OP1.2) 
(OP3.3) (OP1.3) 
(OP3.4) (OP1.4) 

30 (OP3.5) (OP1.5) 
(OP3.6)(OP1.6) 
(OP3.7)(OP1.17) 
(OP3.8MOP1.18) 
Step 2: For each DC I: 

35 Compute the values 



AVO t - 
(OP3.9) 




45 



50 
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to 



15 



MODEL 


WHERE USED 


Inventory positioning models Cor multi- 
item and two echelons; 

Setting inventory requirements 

Estimating stock-out probability for a 
given replenishment quantity 


Strategic 
Planning/ 
Operational 
Planning 


Strategic models for vmr contract setup: 

Computing maximal average service levels 

Minimizing average DC echelon inventory 
levels 

Computing optimal operating parameters 

Checking compatibility of a given set of 
constraints 

Determining production and delivery 
schedule 


Strategic 
Planning 


Operational models 

Determining joint production-delivery 
plan 

Maximizing short-term service levels 

Minimizing average DC echelon inventory 
levels 


Operational 
Planning 



Usage of VMR Models 



35 



Component Procurement Policy Development (CPPD) 230 
Objective 



Determine which procurement policy should be used for which component 
Scope 

45 AO com pon ents in planni ng bill of materials. - 

Features 

Heuristic to identify the procurement policy to use for each component The policies considered are: Just in Time; 
so Bulk purchase, managed via stock policy, such as (s, S); and MRP calculus implying periodic purchase orders. 

Finished Goods Distribution Network Design (FOND) 292 

Objective 

55 

Determine the number, location and capacity of distribution warehouses from a given set of potential locations. 
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Soopo 

Distribution network excluding VMR arrangements. 
5 Features 

Use market demand projections to reengineer the easting distribution network. 

Gobal optimization of system-wide costs including inbound /outbound transportation, fixed and variable warehous- 
ing, and inventory carrying costs. 



to 



Model Engine UtiEties 22 



in addition to the seven modules defined above, there is also a group of general purpose numerical routines that 
are not specific to any of the above seven modules. These routines are collected into a design element referred to as 
is the Model Engine utilities 22. as shown in figure 35A. Examples of the Model Engine utilities 22 include generic linear 
programming solvers; and statistical analysis routines 

An Approximation of the Standard Normal Distribution 

20 Function 

in this section, we suggest few continuous, piece-wise linear approximations for the cumulative Standard Normal 
distrfcution curve. We use the following notation throughout: 



(A.l) 



0 i/8 0 «-«<2<8 l 
a a +^-(z-8 t ) ifd l ^z<d 2 

M M \ 

1 i i^8«-iSZ<8 ffl a *~ 



This function consists of m segments, s»1 m. Each segment s. ranges from break-point 8^ t to break-point 6 r The 

slope of segment s is denoted by d 5 . Hence, any segment s can be written as the linear function a,+a, (a, - a^)- In our 
35 model we limit the functions to be continuous (although unnecessary), thus having 

(A. 2) 



(Bj-S^) for s*2 



Note that in order to define the piece-wise linear function we only require the values . sal n>1 and d„ s«2 m-1 

45 (si nce 3 i°3 m °0). — _. 
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ass 






Remarks 


Symmetric, 
7 segments 


t - -2.7, 
a ■ -1.8, 
, - -0.9, 
4 - 0.9, 
, » 1.8, 
« - 2.7 


a - 0.039923, 
,« 0.164589 
«« 0.351044, 
s o 0.164589 
0.039923 


Enables to reack 
reasonable level of 
accuracy oyer all 
argument's values. 


Symmetric, 
5 segments 


x - -2.7, 

j ** — i • * , 

» 1.4, 
« - 2.7 


a « 0.057692, 

a fl ££071 4 

d«- 0.057692 


th+ 7 geaments . but 
requires less binary 
decision variables. 


Asymmetric, 
7 segments 


1 » -2.5, 
a • -1.1. 
, - 1.1. 
4 - 1.7, 
, » 2.15, 

€ m 2.9 


a- 0.096904, 

3- 0.331213, 

4 - 0.151834, 
5 « 0.063973 
4- 0.021037 


Reaches good accuracy 
levels for the 
highest cumulative 
values . 



Linear Programming (MILP) 

Consider an LP/MILP which minimizes a (linear) function of the decision variables fe(Xi Xm. ... JW and their 

piece-wise linear functions ^(X,) FmPW. M s N. That an objective function of the typo 

(B.l) 



with afl di>0. Similarly to the variables X, Xm Xm , the functions F,(Xj) can appear in the (linear) constraints without 

any limitation; i.a the constraints are of the type 

(B.2) 



For simplicity. but without loss of generality; we assume M»1. Alsa-fardarr^^ 

describe a technique that transforms the function F(T) into a new decision variable, say H, such that the relationship 
H=F(T) is maintained tor any solution obtained by solving the new MILP. 

Algorithm Steps 

Let the function F:3t*->*, be as follows: 
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(B.3) 



Fit) 



10 



15 



F(x 0 ) ♦* 0 *Yi*T 



T=T 0 sO 

T 0 so<rit l 

M 3 



F consists of m segments; segment s is given by [t^t • T m !• introduce the following 2m decision variables: 
Y t - Is a continuous variable (Y,€50 that r epresents the part of segments "covered* by T,s»1 m ; that is, 

V,=max{min{T m . T}-c m . t .O) 

I, - Is a Binary variable (l,e {0.1.2,...}) that indicates whether) that Indicates whether T cows any positive part of 
segments; that is. 



(B.5) 



| 0 if n:^ 
• U otherwise 



30 



To modify the current LP/MILP we do follow the steps below: Replace each F(T) by the term 
(B.6) 



»«0 *•! 



Add the following constraints: 

Y 8 (s»1 m) are the split of T into the segments. 



Hence, 



(B.7) 



5-1 



50 



To maintain (B.5), 

(as) 



Other constraints: 

(as) 



(aio) 
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/g£{0.1}; s^.K.m 

Mean 

5 This algorithm confutes the statisticaJ sample mean of a given time series for a given period of tima 

The input for the routine is the time series , and time periods that the mean is computed over. The output is the unbiased 
sample mean quantity 

Hi"- 



15 



Standard Deviation 

"me algorithm computes the statisticaJ sample standard deviation erf a given time series for a given period of tima 



The input for the routine is the time series X. and time periods n that the standard deviation « computed over 
The output is the unbiased sample standard deviation quantity oy 

30 

Moving Average 

The algorithm computes the moving averages for a given time series for a given period of time with specified aver- 
aging periods. 

35 

x k {K) g x t for k=l,K,n-K+l. 

40 

The input tor the routine is the time series X, time periods n that the moving average is computed over, and the moving 
average period length K. The output is the moving average quantity 



Seasonality Factors and Trend 

50 

Seasonality Factors 

The algorithm computes the seasonality factors for a given time series for a 12-month year period. The input for the 
routine is the time series, and time periods that the moving average is computed over (at least two seasonal cycles). 
55 The output is the seasonality factors. 

Trend 

The algorithm computes the trend information for a given time series for a given period of tima The input for the 
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routine is the lima series, and time periods that the trend is corrputed over. The output is the trend value of the time 



There are several different methods to calculate the seasonality factors and the trend in a time series. The most 
popular ones include Winter's conventional Gnear and seasonal exponential smoothing, and (multiplicative) decompo- 
5 sition method developed by the US. Census Bureau, and its variant X-1 1 method). 

Correlation Coefficient 

This algorithm computes the correlation coefficient tor a given pair of time series with property defined time periods 
10 (there might be certain shifts in time periods in the two time series). 

T (x r Tt) (Y t -D 
rU,r1^ 

15 



£u r »*<r c -?)* 



» The inputfor the routine is the pair of two time series X and Y.areJcorrespondng time periods 
correlation coefficient tor the two time series. The output is the correlation coefficient r(X,Y). 

Curve Interpolation 

25 This conventional algorithm determines a curve with desirable shape to link a set of given points on a 2-dimensional 
space. The input for the routine is the set of given points, and the desired curve shape. The output is the curve that sat- 
isfies the required conditions. 

Weighted Sum of Two Time Series 

30 

The algorithm computes the weighted sum of two time series. 

38 The input tor the routine is the two time series X and Y. the weight factors a and p and the given time periods n. The 
output is the weighted sum time series 

z=(zj;. 

40 — — — 

Coefficient of Variation 

45 This algorithm computes the coefficient of variation for a given time series using unbiased statistical mean and 
standard devlatonL 

50 

The input tor the routine is the time series X and the given time periods n. The output is the coefficient of variation for 
the time series c* 

55 Goodness-of-R (Measure of Accuracy) 

This algorithm confutes the goodness-of-fit (measure of accuracy) tor a given pair of time series: one is the origi- 
nal time series and the other is the simulated one. The input for the routine is the pair of two time series, and cone- 
spondng time periods used to compute the goodness-of-fit for the two time series. The output is the goodness-of-fit 
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(one measure of accuracy) tor a given simulated method The measure of accuracy can taka one of the following forms 
(assume that XoXJt n is the original time series, F^FJ," is the forecast time series and ej - XpFj are the error terms): 
Mean Error: 

5 i A 

1 

Mean Absolute Deviation: 

10 

y 5 Mean Squared Error: 



2D 

Standard Deviation of Errors: 

Percentage Error: 
Mean Percentage Error: 

35 

40 Mean Absolute Percentage Error: 



45 - — 



Regression Equation 
50 . . . . - - 

This conventional algorithm computes the coefficients of a regression equation for a given set of time series. We 
wiD choose a standard computational routine to calculate these coefficients. The input to this routine is the set of time 
series. The output will be the calculated coefficients of the regression equation. 

55 Supply Chain Frame Manager 24 

Overview 

A Frame 16 is designed to integrate User Interfaces, models, analysts routines and data in oider to address a set 



MSE'- 



el 
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of related decision issues The Supply Chain Frame Manager 24 constitutes the backbone of the OSS 1 0 through which 
the User Interfaces, the models in the modules and the data are connected. The Supply Frame Chain Manager 24 facil- 
itates the integration of the client side of the system, with which the user interacts, with the server side of the system 
where the modules and the OSS Database 12 resida 

5 The Supply Chain Frame Manager 24 is responses for two types of integration: System Integration and Functional 
Integration. The System Integrator 310 (see figure 34) is responsible to interpret the client's request dispatch the 
request to the appropriate servers and to coordinate the computation toad and data access. The Functional Integrator 
312 provides the functionality associated with overall supply chain instead of individual frame These functionalities 
include Supply Chain Configuration. Domain Management, user access or privilege administration and performance 

to monitoring or simulation. 

System Integration 

The Frame Manager 24 is responsible for the client-server integration in the DSS 1 0. In this aspect, the Frame Man- 
is ager 24 provides the linkage between the Frames 16. Model Engine 20 and the DSS Database 12; responds to the 
decision requests from the client programs by accessing the models and data; and maintains the "component objects" 
(e g., object Gnting and embedding OLE objects) that share functionality between different Frames 16. Based on the 
decision requests, the Frame Manager 24 launches the appropriate object with the appropriate data, manages the 
requests from different clients for the same service and executes the appropriate server programs. The server pro- 
20 grams execute the request, and return the results to the Frame Manager 24. The Frame Manager 24 win interpret and 
return the results to the Frames 16. 

The high level architecture of the System Integrator 310 is shown in figure 35 and includes a Client Manager 320, 
a Request Interpreter 322 and a Server Manager 324. 

The architectural design of the Frame Manager 24 reflects maximum flaxfoilrty and robustness of the DSS 10. The 
25 client side includes all the User Interface 18 of each Decision Support Frame, such as Demand Management, Supply 
Management etc. The Frame Manager 24 includes two major pieces, the Functional Integrator 312 and the System 
Integrator 310. Two other components running on the server side are Decision Support System Database (DSS Data- 
base 12) and the M a them a tical Model Engines 20. The client program 314 talks to the Frame Manager 24. The Frame 
Manager 24 is the one responsible to cafl individual components running on the server to fulfill the client's request 
30 For example, a user is working on a PSI frame to develop production plan for a specific scenario. After deciding sev- 
eral key parameters, the user wants to check on the production capacity. The user makes this request from the User 
Interface 18 (dick a button or select a menu item). The request is sent to the Frame Manager 24. The Frame Manager 
24 interprets the request and determines that it needs to move the Capacity Checking Model to get the answer. (In a 
more general case* it may need to call more than one Model to accomplish the job.) Then the Frame Manager 24 deter- 
as mines whether a model Server already running and on which machine it is running. If there is one. it sends the capacity 
checking request along with the necessary data, to that server. If there is no Server running at that time, the Frame 
Manager 24 will start up one on a selected machine and sends the request there. Sophisticated dispatching policies 
can be implemented at the Frame Manager 24 to balance the load or improve response times. After the Model Engine 
20 finishes the job, it returns the result to the Frame Manager 24. The Frame Manager 24 then synthesizes the result 

40 — and returns the result to the client = 

When the Frame Manager 24 calls the Model Engine 20, it has two options in terms of passing the data. First, it 
can obtain the data from the DSS Database 1 2 and pass it to the Model Engine 20. This will be done when the amount 
of data that need to be sent to the Model Engine 20 is not very large The advantage of this approach is that the partic- 
ular Model Engine 20 does not require the capability to access DSS Database 1 2. But the data has to travel from DSS 
45 Database 1 2 to Frame Mana g er 24 and then from Frame Mana g er 24 to the Model Engine 20. The second way to pass 
data to the Model Engine 20 is for the Frame Manager 24 to only pass the key information directly to the Model Engine 
20. Then the Model Engine 20 accesses the data directly from the DSS Database 12 using the key information. This 
will be used when the amount of data needed by the Model Engine 20 is quite substantial. e.g. a situation of solving a 
Linear Programming model. The key information passed from the Frame Manager 24 to the Model Engine 20 will 
so include the location of the DSS Database 12. among others: 

The Client 314 only interacts with the System Integrator 310 part of the Frame Manager 24. The Functional Inte- 
grator 312 part of the Frame Manager 24 provides the functionality through the System Integrator 310. The relationship 
between the Functional Integrator 312 and the System Integrator 310 is logically the same as the relationship between 
the Model Engine 20 and the System Integrator 310. 
55 The System Integrator 310 in turn is composed of the Client Manager 320. the Request Interpreter 322 and the 
Server Manager 324. The Client Manager 320 manages and monitors the client connection. For example, it may dis- 
connect a client if the client's machine is down or rf the cOent is inactive for extended period of time. The Server Manager 
324 manages the server side connection. It is responsible to start up and shut down servers. It is also manages dts- 
parching. The Request interpreter 322 is the one that the client directly interact with. It wiD parse the client request and 



95 



EP0770967A2 



generate request to the servers. It wiO consult with the Server Manager 324 before making connection to one specific 
server. 

The high level object representation of the system integrator 310 portion of the Frame Manager 24 is shown in fig. 
ure 36 and the high level architecture is depicted in figure 37. The implementation documentation can be found in 
5 Append* C. 

Functional Integration 

The Functional Integrator 312 enables the advanced user to define the supply chain configuration, manages user 
10 access and privileges, supports and enables the customization of the DSS 10. manages domains to support user 
defined data groupings, manages user defined Scenarios 78 and ensures data consistency across the DSS 10, and 
dynamically monitors the impact of the user's decisions on the performance of the entire suppry chain by using supply 
chain simulation. 

15 Suppry Chain Configuration 

The Suppry Chain Rama Manager 24 allows the advanced user to specify the configuration of the suppry chain. 
The advanced-user win be able to specify the structural (static) elements of the supply chain. These include: Customers 
or Equipment; Products or Repair Hems; Components; Production Resources or Repair Resources; For each of these 

20 structural elements, the advanced user wiD be able to define the various attrfoutes such as; Names and the values of 
features; Group definitions; and Nodes and locations. 

In addition, the advanced user will be able to define the interrelationships between these structural elements. 
These interrelationships include: Distances, costs, and flow limits on the arcs between the various nodes of the net- 
work; Customer-Product-Resource (Equipment-Repair Item-Resource) relationship matrix; Bill of Material structure 

25 that relates components to products; and Production Matrix that relates production resources (repair resources) to 
products (repair items). 

The data flow diagram associated with the Supply Chain Network Configurator 330 is shown in figure 38. 
User Access and Privileges 

30 

The DSS 10 is a secure system where a userid and password are required for access and is managed by a User 
Access and Privileges Manager 331 . An account consists of a userid. password and membership in various groups. A 
user derives rights from group membership that can be individually amended The DSS System Administrator is 
responsible tor assigning each user to a group and assigning rights to every new account. The lowest access possible 
35 allows read only access to one specific frame, with no ability to save Scenarios 78 or domains. Each table in the DSS 
10 database 12 has a designated owner. Only the owners are allowed to update the DSS Database 12. A scenario can 
be used to update the DSS Database 12 when the user who generated it is the owner of the data table that needs 
update 

■ 40~ Customization 

The DSS 10 is customizable to the application and environment where the tool will be used. The customization 
involves: Terminology and nomenclature. Modules and models in the Model Engine 20. Displays and reports, and 
Graphical User Interface objects. t 

45 ThefirsLtwo aspects o^c^storr^zation are administered b y the analyst/systems ad ministrator. For the la st two 

points of customization, the user has the flexfoility to customize displays, reports and QUI objects. The DSS 10 uses 
the proper terminology in the User Interface 18 for the information presented to be dear and intuitive The OSS 10 con- 
forms to the user's environment and nomenclature. The DSS 10 uses a table of terminology to implement the nomen- 
clature suitable to the user's application environment Images on buttons as wen as text are dynamically adapted to the 

so local environment at other the time of installation or execution. Screen appearance elements, such as colors and fonts, 
are modifiable through a User Preferences window. The user has the ability to change the layout of screen elements. 

Domain Management 

55 The Supply Chain Frame Manager 24 provides the user with the ability to define combinations of products, custom- 
ers, and resources to be reused in the context of various analyses. These are called Data Domains and are managed 
by a Domain Manager 332. 

Data Domains provide a convenient mechanism far the user to define the products and customers with which (s)he 
is interested in working. For example, an account manager can define a data domain that consists of the customer 
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accounts that (s)he is responsible for. A data domain is a set of customer, product or resource combinations. Data 
Domains may be used from different Frames 1 & The data domain can be defined at various levels of aggregation (res- 
olution) along each dimension: Productfcroduct group, customer/customer group and resource/resource group. A data 
domain is independent of a data source (forecast, point of sales, shipments). The data sources are determined by the 

5 type of analysis that is performed and are therefore contingent on the frame where the data domain is used. For exam- 
ple, a domain can be used in the context of the sales promotion analysis functionality and could also be used for tore- 
casting: different data sources wiQ be used in order to perform each analysis but both refer to the same data domain. 
Not attaching a particular time range or data series to the Data Domains fadfitates their portability from function to func- 
tion and frame to frame. The user is allowed to build, ecfit and delete Data Domains that are owned by the user, tn adcfi- 

to tion. the user is allowed read-access to the definitions of the Data Domains of other users. This facilitates a set of users 
to perform similar analysis and share carefully constructed Data Domains. The Data Domain Database comprises two 
tables: Domain Description and Domain Definition. From these two tables, the list of available user domains and the 
member tuples of each domain can be created and displayed for the user. The domain management interface can con- 
sist of multiple tree-views. Each tree-view represents the logical grouping of customers, products or resources. From 

is each of the tree-views, the user can select the product, customer, or resource combinations and add the selection to 
the domain. The User Interface 18 should optionally reflect the data availability, and the intrinsic relationship between 
the customers, products, and resources. For example, if the user chooses a specific customer first he should be able 
to choose only the products that are sold to this customer (or any product, depending on his preference) to make a 
domain. Since a customer (or product or resource) can belong to multiple customer (or product or resource) groups, the 

20 user should be able to visualize the groups in which the customer (or product or resource) is a member. This can be 
visually implemented by reversing the tree-view, based on user selected customer (or product or resource). This tree- 
reversal will display the bottom-up version of the tree, rather than the usual top-down. Data Domains can also be 
dynamically constructed based on the features of the product For example, a PSI user can use the domain manage- 
ment tool to define that a data domain to consists of Televisions with 1 9" screen and GR3A chassis. The tool will then 

23 generate a data domain that consists of afl the televisions with these features. The data domains contains the data 
groups which a DSS user is interested in working. For example; a plant manager can define a domain that consists of 
products and production resources. An air force commander can define a domain that consists of aircraft and Gne 
repairable units. The domain can be defined at various levels of aggregation along each dimension. Once a domain is 
defined and saved, it can be retrieved and used in the context of various decision analysis. Figure 39 shows the process 

30 of using the Domain Manager 332. and also shows the operations of the Domain Manager 332. 

Scenario Management 

in the context of the different Frames 16 users generate changes to databases or instances of visual objects that 

35 can be saved as Scenarios 78 which are managed by a Scenario Manager 334. 

Scenarios can contain: edited data, results of analysis, graphs and charts, and performance metrics 
The Supply Frame Chain Manager 24 supports the following functions regarding Scenarios 78: 
Save: Scenarios are saved in the local database. 
Load: Saved Scenarios are loaded. 

40 -Edit: Saved Scenarios are modified. 

Delete: Saved Scenarios are deleted. 

A Scenario 78 can be used to update the DSS Database 12 when the user who generated it is the owner of the 
data table that needs update The Supply Frame Chain Manager 24 maintains the data consistency across the entire 
DSS 10 by restricting the update of the DSS Database 12. Scenarios 78 have note fields to allow the user to enter free 

4 5 form comments. Scenarios 78 should have a date starry to indicate the time of last modification. Scenarios 78 are typ- 
icalty defined within a frame and are associated with a user. Scenarios 78 are specific to users but can be accessed in 
the context of different Frames 16, providing that the user has the adequate access privileges. This enables the output 
of an analysis in one frame to be saved as a scenario and used as an input in the context of another frama Scenarios 
78. while belonging to specific users, can be shared between users. A scenario may be deleted only by the user who 

so created it or the system administrator. A user should have the facility to toad the scenario from different workstations. A 
user should also be allowed to load portions of a scenario into a different frame. For example, a user is able to save the 
top-down and bottom-up forecasts from the Demand Management Frame 130, and load the top-down forecasts in the 
PSI Frama The DSS 10 should warn the user in case of data incompatfoflity. A user is able to save the models and the 
parameters that were used to modify loaded data The user is then able to apply these models and parameters to drf- 

5s ferent data seta 

A frame 330 has several forms 332 associated with it as depicted in figure 40. If the user attempts to dose a form 
on which data 334 has been changed, the user wffl be prompted to Save the changes to a scenario. Abandon Changes, 
or Update the actual database Updating the actual database requires necessary access privileges. A Scenario 78 is 
anchored to a frame, and can have multiple forms associated with it A Scenario 78 can be loaded into the frame to 
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which it is anchored, in which case, all the data and other information wiO automatically be loaded into the appropriate 
locations. Alternately, a Scenario 78 can be opened to access specific data that are contained In the Scenario 7a This 
feature will enable the user to load the data created in a different frame to a different frame. To facilitate this implemen- 
tation, forms are specified to have a pre-specified number of date-'pockets. - Elements of a scenario include: 

Header information for each of the data pockets in each of the forms of each of the Frames 1 6. For example. DM- 
1-{1]oPOSl245*Point of Sales Information May 25. 96; DM-H2]»TD1245- Top Down Information May 25. 96; and 
DM-H3]=>BU1245* Bottom Up Information May 25. 96. 

Model and parameter information. For example, ARMA with (1,1) applied to Top Down data. 

Graph and parameter information 

User comments 

Date stamp 

Performance monitoring using simulation 

Two levels of integration required in supply chain Decision Support Systems have been embedded in our DSS 
architecture; data integration and decision integration to provide a Network Simulator 350 (see figure 37). The former 
has been obtained by having a common Decision Support System (DSS) Database 1 2. from which input data to the 
decision models are retrieved and outputs updated. By having such bidirectional data flows between models and the 
Database 12 a complete data level integration is realized. In order words. aO decisions are based on consistent and up- 
to-date information. This is the primary level of integration for a supply chain DSS 1 0. 

The secondary level of integration is the decision integration. The purpose is to avoid sub-optimization among func- 
tional processes. An ideal case would be to have a "meta analytical decision model* which could optimally solve the 
entire supply chain wide problem. With the state of the art in decision sciences and computing, thisrs not. Thus, in our 
DSS architecture, various Frames 1 6 are (inked by the performance simulator. For instance. Forecast Data 1 46 from the 
Demand Management Frame 130 is used in PSI planning and VMR 250 frames. VMR schedules are entered to the PSI 
planning and so on. With this approach, it is necessary to have a supply chain wide performance simulator to monitor 
the effects due to the systems dynamics along the supply chain to provide a functional integratloa The purpose of such 
an integration is to provide the user visibility beyond his functional boundary in order to facilitate a feedback control. This 
feedback will make H possfole to dynamically monitor the impact of his decision on the performance of the entire supply 
chain. 

The discussion below begins with background on decision integration and the system architecture Then, the 
underlying supply chain simulation modeling logic with regards to data flow and process flow are described. Finally, 
originality of such an approach to use a supply chain simulator tor the DSS integration is discussed. 

High Level Architecture 

The Simulator 350 resides at the Supply Chain Frame Manager 24 as a Functional Integrator 312 together with the 
Network Configurator 330 and Domain Manager 332 as shown in figure 37; Supply Frame Chain Manager - High Level 
Architecture. The Simulator 350 can be initially configured with product flow, network structures and domain information 
with the other modul^of the Functional Integrator 31 2: Th^^ major decisions fronvtheindk 

vidua) Frames 1 6 that will have impact on the total supply chain performance Monte Carlo simulation wiU be carried out 
driven by demand processes captured from the domain information and replenishment and PSI decisions from the DSS 
Frames 16. Total systems performance representing the supply chain dynamics will be tracked according to the per- 
formance matrices specified in our DSS specification. These mainly cover cost and service tradeoffs including fil rates 
~andrespcnsetimes.-Tto 

etons. distrfoution channels and the total system. In essence, the architecture facilitates the primary objectives of com- 
plementing decision integration among models to provide a cross-functional optimization. 

User Interface . 

User Interlace 18 of the performance Simulator 350 will have three major features; network configuration, decision 
and parameter settings and the simulation and monitoring. 

Network Configurator 

The system will invoke the Network Configurator 330 module of the Functional Integrator 312 at the Supply Chain 
Frame Manager 24. Detailed features and User Interfaces have been described in the previous sections. 
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Decision and Parameter Settings 

Parameter, frame decision settings and empirical demand distributions wOl be displayed in the editable screens. 
These screens wtO also be accessible during the simulation run so that the user can interrupt the execution and modify 
5 the parameters interactively. The following screens are included: Demand distribution screens and Frame decision 
screens. 

Performance Monitoring and Simulation 

10 The user is able to visualize the impact of the decisions taken at the level of one frame on the overall performance 
metrics of the entire supply chain. The Supply Frame Chain Manager 24 supports this performance monitoring func- 
tionality. In all the Frames 16 users can easily access the "performance monitoring screen." The performance monitor* 
ing screen displays global performance metrics that are available to aO users and that cannot be deleted or modified. 
The performance is tracked and displayed along the: channel (such as VMR, Non-VMR, etc.); echelon (such as sup- 
is pGer, plant DC and stores); individual nodes; and the total system. The performance monitoring screen also contains 
user formulated performance metrics that are customizable and available only to the user who formulated them. 

The Supply Frame Chain Manager 24 supports the following functions for user formulated performance metrics: 
Formulate: a new user-formulated performance metric, Edit an existing user-formulated performance metric and 
Delete: a user-formulated performance metric. The function "edit" and "delete" are restricted to the user who defined 
20 the performance measura 

The value of the performance measures can be updated each time the user modifies the value of a field in the local 
database associated with the frame in which the user is working or by using an explicit recalculate function or at user- 
specified time intervals. 

Users can choose "a ticker-tape" to always display the current values of user selected key measures. 
2S The User Interface 18 is designed to support the conventional "Visual Interactive Simulation (VIS)" approach. 
According to this approach, the simulation can be carried out not only in the batch mode but also in the event-by-event 
or period-by-period mode. The performance metrics could be viewed and parameters adjusted interactively. To facilitate 
this approach: 

Inventory, service level and cost profiles for each aggregated measure (such as node, channel or echelon) wiD be dis- 

30 played as time series graphs. This win highlight the systems dynamics along the chain. 

Summary performance matrices win be displayed in the summary report screen or saved to a file. 
Sirrvlation Logic: Data Flow Description 

The supply chain simulation model primarily mimics the material and information flow controlled by the frame deci- 
sions along the supply chain (see figure 41). The Simulator 350 is built around data tables for each node which are 

as linked according to the information and product flow. These data tables are stored as simulated data in the system. 

In the initialization phase, these data tables will be populated with inventory information including inventory posi- 
tion, on hand, on order and schedule receipt Then, these tables are connected using pointers according to the network 
structure, order and product flow directions. Then, demand and lead time information is loaded from Demand Manage- 
ment Frame 1 30 through system integrator and appropriate distribution is built Using the distributions, customer orders 

40 are g eneratedaccortf ng to the. demands process es at the customer facing ech elon and replenishments are triggered 

according to the control rules along the logistics pipe line for each event due tima 

The major inputs required are the decisions that win effect the total performance of the supply chain. The following 
are included: FGDND or Network Configurator - Network design and Product flow; Demand Management - Forecast 
and forecast errors; Vendor Managed Replenishment • Replenishment policy, Target inventory, and Delivery frequen- 

45 cies; PSI Planning - P' fine and its variation, and I* line and its variation; Supply Management; and Component inventory 
^icyarid parameters; 

Depending on the conf iguration of the network, other supply chain system parameters such as FQ inventory policy and 
parameters may also be needed for the non-VMR channel. 

The outputs from the model are based on the performance assessment plan of the DSS 10 for a commercial setting 
so including the followings: Supply responsiveness, On-time delivery performance Fill rate, FG inventory levels, Compo- 
nent inventory levels, Order cycle time, and Financial measures. 

The Simulator 350 builds up the above performance metrics from the event-level (lowest) measures. This "bottom- 
up" approach in simulation makes it possible to support user formulated performance matrices that will be customiza- 
ble. 

59 Simulation Logic: Process Flow Description 

A more detailed process flow of the simulation engine can be described in terms of either the demand processes 
or the control rules. Two basic control rules considered in our DSS 10 are production (reconciliation) policies and 
replenishment (inventory) policies. 
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Demand Processes 

Ths parformanc® of the total supply chain mainly depones uptmi tin© control poficies and parameter settings along 
the multilevel material and information flows from the supplier to customers. Both independent and dependent demand 
s processes will be supported. They dictate the way requirement at eatft node is generated In the independent demand 
customer orders are generated tor all nodes from random distributions developed from the Forecast Oats 1 46 at each 
node. In the dependent case, customer order generation from th© random distribution is applied only to the customer 
facing echelon The demand for the higher echelons arc calculated from the lower ones with the lead time offsets. 
Th© following systems will be driven by independent demand processes: Vendor Management Replenishment 
10 (VMR); Continuous Replenishment (CR); Reorder Point System (r, Q); Just-in-time (JIT): and WBn-Maa (s, S). 

The following systems wiO be driven by dependent demand processes: Distribution Requirement Planning Systems 
(ORP); and Materials Requirement Planning System (MRP). As for the case a? One-far-one (S-1. S) system for the 
repair systems, Pcisson demand process wffl be applied. Demand generation win ba carried out by an inverse transform 
of the specified distribution. For high volume items, normal approximation o? forecast error will be used. For th® others, 
is empirical distributions wiO be used. Time series forecast and its error cfisarfeution (or parameters) wffl be obtained as 
frame decisions from Demand Management 

Replenishment Processes 

so Both putt versus push controls are supported. In the pufl oontro3 system, inventory is depleted by demand and 
whenever it reaches the replenishment point an order is placed to a supplier. In the VMR, the supplier places a reverse 
order to the store. For the demand channel, inventory decision processes (models) for the following putt systems wiD be 
included: Vendor Management Replenishment (VMR); Continuous Replenishment (CR); One-tor-one Replenishment 
(S-1 , S); Reorder Point System (r, Q); and One-for-one system for repair will be logically treated the same as the Con- 

& tinuous Replenishment in the commercial settings. 

For the push (planning) systems a time-phased plan for the planning interval is established and replenishment is 
triggered based on the requirement schedule receipt and on hand inventory. For the demand channel pufl systems 
are: 

Distribution Requirement Planning Systems (DRP) 
30 Similarly, for the supply channel, the following pull systems will be supported: Justin-time (JIT); and Min-Ma* (s, S). 
The push planning systems tor the supply channel are: 
Materials Requirement Planning System (MRP) 

Transportation and information flow logic will be embedded in the replenishment processes. The capacity limita- 
tions, cos* and lead time for various modes of transportation and information flow (orders) wiQ be checked to execute 
& the replenishments. 

Reconciliation Processes 

The production planning logic refers to the way MPS is created Given a PSI plan ISO for the planning horizon with 
40— possible variation, r the system need to track the dynamic outcomes along, the supply-chain.JThis wiO be carried outby. 
generating the dynamic demand along the demand channel and consolidating them to obtain the simulated S' One. The 
simulated S' One (line refers to as the time series sales information) will be checked against P' (production) and F (inven- 
tory) lines of the PSI plan 190 to compute service fill rates. Then production plan P* Gne will be offset by simulated pro- 
duction lead times. 

43 Qnce the actual P* line is-established, component usage can be computed usng the BUI of Material (BOM) fables. 
This usagsTis translated as requirements (demand) to the supply channel. Then, component flows along the supply 
channel will be traced according to the respective component replenishment policies and demand processes at each 
node following a simitar logic as described in the demand channel. 

so User Interface 18 

One of the primary objectives of our DSS 10 is to provide a decision support environment that facilitates fie decs- 
sion-maWng processes using quantitative models and associated business data. The interaction between the users and 
the DSS 10 during the decision-making process can be characterized as follows: The communication of process intor- 
55 mation and management input; Formulation of decision problems: Generation of problem solutions or evaluation of 
decision alternatives; and Coordination of the above. 

To facilitate the communication and coordination between the users and the DSS 10. it is necessary to choose the 
appropriate User Interface 18 design paradigm. 
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User Interface Design Paradigm 

The User Interface 18 is based on the conventional human computer interaction paradigm referred to as "direct 
manipulation". In this paradigm there is no clear separation of input and output For example, in exercising a certain 
5 model the user may either evaluate the impact of a decision option by specifying the decision variables or generate the 
optimal values of the decision variables. In the former setting the decision variables serve as input while, in the latter 
setting, the decision variables constitute the output 

Another characteristic of the direct manipulation paradigm is the quick feedback feature where a user initiates an 
action such as posing a particular query through direct manipulation of some interface object and the system responds 
to with reasonable speed. 

User-DSS Interaction 

In each Decision Support Frame discussed previously, the users wil be aided in making several decisions. The 
1$ principal process underlying these decisions wffi serve as the basis for the design of the User Interface 1 8. 

A typical user-DSS 10 interaction (see figure 42) begins with the users reviewing 402 the initial conditions and 
default values related to a decision problem retrieved from the DSS Database 12. Then the users communicate their 
preferences through proper selection of options, specification of parameters and values, and choice of analysis rou- 
tines. The DSS 10 examines the inputs provided by the users and assists the users in resolving any inconsistency in 
20 the inputs. Then, to look for the solution of the problem, the DSS 10 invokes the decision logic 76 of the frame. The Skip- 
ply Chain Frame Manager 24 associated with the frame executes the appropriate quantitative models and routines in 
the Model Engine 20. The users can review the output through the User Interface display, and repeat the above process 
if warranted. 

The general guidelines for the preferred User Interface design are described in the next subsection. 

25 

Design Guidelines 

The genera! design guidelines are as follows: 

30 User Friendliness 

intuitiveness: Conformance to established standards. 
Integrated graphical display: Simple and visually clean graphical screen layout 
User customization: Ability to customize the interface into user's desired style. 
35 Minimal typing: Use of menus, pull down Gsts and buttons. 

User Guidance 

Flextole sequence control: Ability to access the DSS 10 functionality without a pre-imposed sequence. 

_ 40 — — Context-sensitive on-line h elp . — 

Semantic feedback: Use of visual and audio cues for conf irmation and progress. 
Use of colors tor clarity, focus and aesthetics. 

User Interaction 

45 _■ 

Data visualization: Visual aids to interpret data. 
Object orientation. 
Local/remote concurrent usaga 

Single/group usage. Ability for multiple users to collaborate in decision making, 
so Multiple levelsof user expertise: Support for novice as well as advanced users. - 

Implementation Principles 

Consistency: Similar "lode and feeT for userinterface objects across the DSS 10. 
55 Modularity: Reusable ami object-oriented user-interlace coda 
Configurability: Adaptability to the specific user environment 
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Design Elements 

The key design elements for the OSS User Interface 18 include; Frame QUI; and Standard Object Library. 
Frame GUI: Since the DSS 10 wiD be an interactive environment, we adopt the most common environment used for 
5 interactive computing, known as the WIMP environment which stands for Windows. Icons, Menus, and Pointers. A 
frame-specific graphical User Interlace (GUI) in this environment is necessary to support the interaction between the 
users and the OSS 10 in a decision process. The Frame GUI is customized using a standard set of User Interface 
objects. An example of this Frame GUI is given in figure 43. 

Standard Object Library: The standard set of the User Interface objects used to bufld Frame GUIs is contained in a 
w standard object Ifcrary. The forms, positions and contents of the objects are set according to the specific needs of each 
Frame GUI. For example, these are the sample objects in the standard library employed in the PSI DSS shown in figure 
43. 

Selection: to choose among various action options 
Grid: to input data and display results 
15 Chart to display input data and results graphically 
Command Button: to execute an action 
List Box: to list user choices 

Example Implementation Architecture 

20 

The basic objective of the DSS 10. is to provide customized decision support for the decision makers to manage 
an integrated agile supply chain, ft generates the following two specific systems requirements: DSS 10 should provide 
decision support capabilities that work with the prevailing information systems which is mainly data transaction based 
systems. These decision support capabilities may include data analysis, decision process modeling, scenario manage- 
rs ment among many others; and OSS 10 must integrate data from various sources along the Supply Chain Information 
Systems IS. This requires the DSS 10 to interact with multiple information systems to gather raw data and distribute 
processed data 

These two basic systems requirements motivate the architecture and the choice of the platforms. 

30 Three-tier DSS Architecture 

In an enterprise-wide supply chain, the potential users of the OSS 10 are decision makers with different operational 
responsibilities and concerns. The views about the supply chain and functional requirements for decision support may 
therefore vary accordingly. The data to support these functional requirements reside often on a number of information 

35 systems possibly with different hardware and software platforms. Consequently, the DSS 10 needs to interact with the 
users through a unified User Interlace 18 to address diverse business concerns while it should also be capable of inter- 
facing with different Supply Chain Information Systems 15 to gather and distribute data. 

To that end, we have developed a layered systems architecture design for the DSS 10 as shown in figure 44 in 
which all major system components interact with each other in a layered fashioa Aside from other benefits, the layered 

49- design makes the choice of platform 

ent, and permits standardized interfaces among various system components. The DSS architecture can also be viewed 
as a three-tier architecture consistent with the commonly understood three-tier client-server information systems archi- 
tecture consisting of the User Interface 18, the Business Logic 350 and the Data Management tiers 352 as illustrated 
in figure 44. 

45 Each of the three tiers irt the DSS architecture has its distinctrve functional roles ar^ 

system complexities. The platform for the three tiers is preferably chosen to best fit the user's unique functional and sys- 
tem needs. The choice is complicated by the availability of a number of competitive software and hardware platforms 
and the realization that there may not exist a single "optimal" suite of platforms. In the following, however, we describe 
a suite of platforms that can best serve the general DSS 10 needs and also be in line with the forecasted future deveh 

so opment trends in information technology and enterprise-wide distributed computing technology. 

Selection of DSS Development Platforms 

To support the supply chain wide decision making, the DSS 10 needs to be integrated, flexible, responsive and 
55 comprehensive. One major obstacle, however, is that most of the data required by the DSS Database 12 are stored in 
various Supply Chain Information Systems 15 that are based on an older information and computing technology, 
designed to support vertically integrated organizations, built in isolation, and usually very complex. Such systems are 
generally referred to as the legacy systems. Therefore, to meet business and systems needs, the DSS 10 environment 
should: provide common and easily understood interfaces to all users, enhance the current business Knowledge and 
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skills, model and incorporate business logic, and promote access to legacy data and application systems in a secure 
manner. 

The development platform environment 370 illustrated in figure 45 has been chosen as the preferred environment 
to meet the above requirements. 

5 In this development environment 370, Microsoft Visual Basic 372 is used to build the unified User Interface 1 8 and 
the Business Logic 350 that includes the Frames 16. Supply Chain Frame Manager 24, system level services and 
Model Engine 20. Portions of the Model Engine 20 that require more efficient and precise numerical confutations are 
preferably implemented using the Visual C++ programming language 374. 

The Visual Basic codes 372 directly interface with the DSS Database 12. The DSS Database 12 uses Microsoft 

10 Access 376 which, in turn, interfaces with the Supply Chain Information Systems 15 through either Windows ODBC 
(Open Database Connectivity) tools 378 or Microsoft SQL Server 380 in a dientfeerver fashion. The Supply Chain Infor- 
mation Systems 15 can include data servers in IBM SQL/DS. UNIX Oracle, among other formats. 

The Windows NT 382 is operating systems for the local area network server while the User Interface 18 can be in 
any Windows environment (3.1 and above) 384. 

is In this environment it is important to establish the dientfcerver data linkage between the DSS Database 12 
(Access engine) and the supply chain information system data servers. 

As described earlier, the DSS Database 12 is internal to the DSS 10 implementation and contains only the data 
needed for the execution of the DSS 10. The data in the DSS Database 12 is synthesized from a variety of sources in 
the Supply Chain Information System 15. The DSS Database 12 can be interfaced in a Client Mode 30 to the supply 

20 chain information sources tor data retrieval and update, as needed. This client-server interface, rather than a hard link, 
has the advantages discussed below. It ensures that the DSS 10 can be linked to the heterogeneous information 
sources in the supply chain. This is particularly significant in the absence of an enterprise-wide integrated information 
system for the stppty chain. It reduces the burden on DSS Database management by obtaining updated data only 
when necessary. It fosters independence of the DSS 10 for easy maintenance, It facilitates development of the DSS 10 

25 for a generic supply chain architecture and minimizes application specific customization. 

The architecture described herein is built upon the general client-server concept In the following, we describe the 
hardware system architecture (see figure 46) for generic systems, in which the host 398 represents the Supply Chain 
Information Systems 1 5. and the PCs 400 in the Local Area Network (LAN) 402 supports the DSS 10 applications. This 
architecture supports storing the invention described herein on various types of storage including RAM. ROM. hard and 

30 floppy disks, etc. 

In the architecture of figure 46. we assume that the hosts 398 contain the majority of transaction level data and they 
will communicate with an LAN 402 where the DSS 10 resides. Here, we do not make specific assumptions about the 
type of the hosts (IBM mainframe or UNIX workstation). On the LAN 402. there will be a servers) PC 406 and a set of 
linked client PCs 400. Specifically, the functions of the DSS 10 can be partitioned as illustrated in figure 47. 
35 Below we describe the basic system requirements and functions for the system components in the above diagram. 

LAN: 

Basic Requirements: 

^ 

Local area network supporting standard protocols such as TCP/IP, IPX/SPX, Named Pipes/NetBEUI etc. 
PCs can run Windows NT or 95 

Basic Functions: 

Provide the communication media between client PCs to server PCs 
Permit external PCs to dal into the network using regular telephone fines 
Allow connection to the IBM hosts 

so Client PCs: 

Basic Requirements: 

Have sufficient speed and memory 
55 Have network connection (on the LAN or dial-up through telephone line) 
Can run Windows 95 or NT 
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Baste Functions: 

Serve as OLE clients 
Provide primary User Interface 

5 Implement what-if scenario manager 
Contain localized database 

Server PCs: 

10 Basic Requirements: 

Have maximum speed, storage space, memory and network connectivity 
Run Windows NT, SQLServer and SNA Server 

15 Basic Functions: 

Be the OLE server 

Host main DSS Database 12 with a library of SQL queries 
Serve as the SNA Server to exchange data between the DSS DB and host data tables 
20 Implement model object Itorary 

Contain external optimization solver 

Hosts: 

6 Basic Requirements: 

Standard IBM database and applications or UNIX based database 
Support any combination of the options (Ethernet Token-Ring, or FDDI) 
SOLC 

30 X.25.QLLC eta 

Basic Functions: 

Provide raw supply chain wide transaction data 
35 Contain EDI or other connections with customers and suppliers 
Support overall business information requirement of the company 

Example of Use 

40 User Access and Privileges 

When the DSS 1 0 is invoked, the DSS logon dialog box will be displayed to the user (see f igure 46). Failure to enter 
a valid User ID/Password combination results in the DSS 10 immediately terminating. Correct entry of a valid user ID 
and password results in the DSS 1 0 being started and the opening screen being displayed to the user. The user ID is 
45 visible as it is typed by the user, but the password is blocked to prevent casual observation while it is being typed The 
user (D is checked against an internally maintained table to ensure authenticity and user's privilege. 

Opening Screen 

so Once the user has successfully logged on to the DSS 1 0. the opening screen is presented. Presenting the opening 
screen and deciding which frame the user is able to access is the responsfoiOty of the Supply Frame Chain Manager 
24. The main feature of the opening screen is a graphical outline of the supply chain overlaid with the relevant Frames 
16 and showing the relevant portion of the supply chain. The user may move the mouse pointer over any of the Frame 
Boxes and dick within the box to launch the frame (see figure 49). 

55 The user may also directly access the Frames 1 S from the Toolbar buttons. The user must have the correct privi- 
leges to access the selected group, or an error message wiD be displayed alerting the user that he does not have the 
correct privileges. 
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User Preferences 

A feature of the DSS 10 available from the main DSS screen is the User Preferences Folder. This folder allows the 
user to change certain features of the OSS 1 0 to preferred settings. Aspects of the screen appearance, layout and tunc- 
5 fonaJity will be modifiable by the user. These preferences are saved and remembered between different OSS 1 0 user 
sessions (see figure 50). 

Domains 

to Select Data Domain 

The primary interaction screen for the Domain functionality is the Select Data Domain dialog box (see figure 51). 
The purpose of this dialog box is to display a list of all domains available to the user, ft also allows the user access to 
dialog boxes for, editing, creating and deleting user domains. This set of functions constitutes the core functionality for 
15 the domain object 

The major features and functionalities of the Select Data Domain dialog box are discussed below. An area showing, 
in a graphical way, the available domains. This list is built from two separate lists of domains. One set of domains is a 
default list of domains available to aO users. The second set of domains is a user-specific set of domains. This set of 
domains can be created, edited and deleted by the user. The default set of domains is immutable. Each domain is rep- 

20 resented by a folder. Double clicking on a folder selects the folder and adds it to the Currently Selected Domain text box. 
Double cfidang on a folder expands the folder and shows the customer-product tuples that are within the domain. An 
area showing the currently selected domain name. A button to allow Loading of the currently selected domain. A Cancel 
button to allow the user to exit the dialog box without selecting any domain and without initiating a toad operation. The 
Cancel is only valid for operations performed on the current dialog box. Editing operation performed during the session 

2f will persist. An Edit Domain button to allow users to modify existing domains, create new domains and delete unneeded 
domains. This functionality is only available for user-created domains and not for default domains. 

Edit Domain 

30 The Edit Data Domain function allows the user to create new, user-defined domains and add them to the list of 
existing domains. In addition, the edit domain window allows the user to modify existing domains and delete unneeded 
domains. The user can create tuples from a tree-like listing of all available products and product groupings and all avail- 
able customer/customer groupings. The user may add as many tuples to the new domain as necessary. The user must 
give the domain a unique name and save it It is then added to the list of available domains for the user (See figure 52). 

35 The major features and the usage of the features of the Edit Data Domain dialog box are discussed below. To cre- 
ate a new domain, the user must dick the Add New Domain button on the tool bar. This wiD create a new domain in the 
list of existing domain and open a name change box over the name of the domain so the user may give the new domain 
a unique name. To add a new tuple to a domain the user must have a selected domain in the domain list Next the user 
must dick on a product or product group in the product tree and/or a customer or customer group in the customer tree 

_ 40 and dick the Add to Domain button on the toolbar to add the selected tuple to the selected domain. Only one prod 

uctfcroduct group and one customer/customer group may be selected at a time. Selecting a group will result in aggre- 
gated data for the selected group being displayed. If data for the members of the group will be needed, the system wilt 
assist the user by displaying the data at appropriate resolution. However, some analysis may require that all of the data 
for the members be loaded. A shortcut key wiD be provided to allow the user to select all of the products or customers 

45 that make up a selected-groupi The user may select as many tiyles as necessary. To remove a tuple from the new 
domain, the user must select the tuple from the list of tuples to be added to the new domain and dick the Delete button 
on the toofoar. To delete an entire domain, highlight the domain to be deleted in the list of domains and dick the Delete 
button on the toolbar. The user will be warned that this action will result in the elimination of a domain from the DSS 1 0. 
If the user dicks OK the domain is deleted, ff Cancel is clicked, the domain will not be deleted. When naming a new 

so domain: the new domain may not have the same name as an existing user domain nor the same name as an existing 
default domain; and the domain name should be something descriptive to the user so he will remember what the 
domain represents. The user saves the new data domain and exits the dialog box by selecting the OK button, ff the user 
exits without saving the new domain, he/she will be asked whether the new domain should be saved. The user can exit 
the dialog box without saving the new data domain by dieting the Cancel button. Default domains cannot be added by 

55 the user. Default Data Domains are created and added to the DSS Database 12 by a systems administrator with this 
access privilege. The user may choose between four different modes for viewing the Customer and Product trees as 
discussed below. The "Product View* enables the user to first dick on a product or product group in the Product tree. 
When a product or product group has been selected, the Customer tree is updated to display only the customers and 
customer groups that are relevant The "Customer View" enables the user to first dick on a customers or customer 
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group in the Customer tree. When a ajstomer or customer group has been selected, the Produd^^ 
play only the product and product groups that are relevant The •Customer-Product View- enables the user to fret cOck 
on either an element of the Customer tree or an element of the Product tree and see the existing related elements in 
the other tree. The "Neutral View" displays afl customer and customer grotps and all product and product groups wrth 
no linkage between them. This view allows users to select tuples without regard tor the existing relationship between 
the products and a customer. The user also has the ability to reverse the tree and show aO the parental relationships 
involving a selected element of the tree. This is accomplished by way of the Reversed check box located at the top of 
the Customer and Product trees. By dieting the check box the tree is reversed, based on the currently selected element 
of the tree. Either a group or an individual product or customer may be selected. The tree may then be rotated to show 
the groups ft belongs td To restore the view to the normal view, uncheck the check box. 

The user may deselect any selection made in a Product or Customer tree by clicking the Deselect button located 
above the desired trea This wiO remove the highlight bar from the currently selected tree element and leave all de- 
ments of the tree in the unselected state. This is useful if the user wishes to select an element from only one or two 
trees, but not aO. 

Make Product Set 

The Make Product Set dialog box gives the user an alternate way to make a domain which only consists of products 
and product groups (see figure 53). Using this dialog box, the user may select groups of product numbers based on fea- 
tures of the products. This function can be accessed from the Edit Data Domain dialog box by dicking the Make Product 
Set button on the toolbar. This wiD open the Make Product Set dialog box. 

First the user selects a product category from the product category list Then, the user selects a feature (or fea- 
tures) that will be used as selection criteria(i.e.. the Brand) in a combo box in the right part of the dialog box. Once the 
feature selection is made, the possible values for that feature will appear in a fist box below the selected feature name 
The user may then highlight the features desired. Immedately after the feature type (i.e.. Brand) is selected, a new 
Wank feature type selection box appears to the right of the selected feature type. This allows the user to select a second 
feature choice to use as a selection criteria (i.e.. Subtype). Once again, the possible values are then listed in a list box 
below the selected feature type and a third feature type selection combo box appears to the right of the last selection 
con*o box. This process wifl repeat untfl there are no more feature types related to the products. The user may select 
afl of the choices for the feature by clicking the Select * button located directly below the Feature Type dialog box. In the 
following example, the resulting domain consists of products in the "PROJ* product category with brand being *Fi" "PP* 
or -S" and subtype being V or 'S*. The products that satisfy these selection criteria are shown in the -Products" fist 

As the user makes selections from among the Feature choices, the list of products matching the selection criteria 
is updated in the Products Gst box. The user may select a set of these selected products to use as the domain, or may 
choose ail of the products selected using the Select button. When the user has the desired set of products. OK is clicked 
to copy the selection to the Edit Data Domain dialog box. 

Scenarios 78 
S^arios78arrfeoe^ 

save a scenario to retain the what-if analysis work performed. Once a scenario is saved, it may be accessed by other 
users as a means of sharing analysis and planning results among different users. A scenario may also be used to save 
the logic behind a business decision, so the factors contributing to the decision may be analyzed at a later date and pos- 
sibly reused. 

When the user chooses ^Save Scenario from the File men u group, the Save Scenario dialog box is presented (see 
figure 54). At the top of me diafog box is an edit box showing the name of the selected scenario the current information 
should be saved to. If the user wishes to create a new scenario, the name of the scenario is typed into this edit box and 
the data will be saved under this new scenario name. Scenario names must be unique. 

The user has write access to a Scenario 78 to save the modified information to an existing scenario. Scenarios 78 
for which the user does not have write-prrvileges will appear grayed-out in the Save Scenario dialog box. and the DSS 
1 0 wifl not allow the user to save to this scenario. The user may also add a description to the scenarfo and this descrip- 
tion wfll appear at the bottom of the Save Scenario screen. This is a free text area where the user may type any words 
to describe the scenario. Each time the scenario is saved, the Date Updated field of the scenario is automatically 
changed to the current date and time. The scenario is saved when the user clicks the OK buttoa If the user dicks the 
Cancel button, the scenario is not saved. 

If the user wishes to load an existing Scenario 78 . the Open Scenario menu choice on the File menu is selected 
(see figure 55). Scenarios 78 that were created by other users appear with a RO tag. for read only. These Scenarios 78 
may be loaded but cannot be saved. The user may always save these Scenarios 78 to a new scenario, rf desired. 
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Demand Management Frame 

The User Interface for Demand Management (DM) Frame 130 provides the user with a consistent environment for 
carrying out these Five activities: Demand Characterization; Bottom-up Forecasting; Top-down Forecasting. Sales Pn> 
s motion Analysis; and Forecast Performance Evaluation. ^' 

Each of these activities requires a slightly different User Interface to accomplish the task at hand. Therefore, a dif- 
ferent screen is used for each, although they wfll share many common elements, tools, and procedures. Within the OM 
frame, any riumoer of activifies can be operate 

change the view from one screen to anolher without losing any data or configuration information associated with each 
to screen. 

AO DM activities take place within the same data domain, although different Data Domains may be active in other 
Frames 1 6 of the OSS 10. The user can select a new data domain tor the DM activities at any time using the standard 
DSS 10 data domain selection dialog box 

There are several desirable features common to each of the DM screens. Regardless of the area in which the user 
is working, the user is able to perform the following operations: save and retrieve DM configuration information- save 
and retrieve data from the DSS Database 12; save and retrieve OM data as a scenario; display point-of-sales or ship- 
ment data (where applicable); specify Omits on data time series; specify the resolution of data time series (yearly 
monthly, weekty); display data as absolute values, or as percentages of some total values: display data in tabular or 
graphical fomi;de^. cut ccjpy. paste data series vvimin the DSS 10 and Windows environment; and apply functions to 
data in a "scratch* or work area. 

Work Area Pop-up Screen 

In addition to the dedicated screens, a pop-up window is available to act as a scratch or work area. Data series can 
be cut coped, and pasted to and from this window and other DSS windows, as wed as other Windows aooiications. 
Users can use this window to process and analyze data. 

The following sections describe each ot the OM screens in more detail. 

Demand Characterization 

This area of the demand characterization screen enables the user to visualize the selected domain in outline form 
to^^^? ? n8 JT T* StreamS * a"lf '«el of aggregation, and by using the option menu, specify 
the type of data to be displayed: sales history, sales characteristics, or Market Data 140. The Market Data 140 may not 
be always available at the same resolution as the firm's Demand History Data 136. Therefore, special -market Data 
Domains - are created to facilitate access to the Market Data 1 40. 

On the right hand side of the grid the user can choose between a set of summary statistics to be displayed- YTD 

*? e i YTQ y Mr 10 fl0: YTDL Year to date last year; YTDB Year to date budget; YTGB Year to go budget; and 
LiZM LHst 12 months* 

Several analysis tools are available: Trend. Moving average. Pattern changes, Pareto analysis, and conelation 
between products. The output of these analyses can be displayed in table or in graph.- 

Sales Characteristics Screen 

A set c4 Sales Characteristics can be computed and displayed in a special table: average level of demand, trend. 
volatility, and lumpinesa Accessing this table can be done throu g h the menu un der the option «nt ^ 



Bottom-Up Forecast 

The Bottom-Up (BU) forecast screen (see figure 56) contains a Customer Table and a Product Table which have 
so several configurable columns and data display options. BU operations and functions are accessed from the BU screen 
menu and subsequent dialog boxes. 

Customer Table 

55 Since BU forecasting is a customer-driven operation, the topmost table displays the customer tree for the selected 
domain. Onfy those domain entries which are strictly customer-oriented are shown in the customer table Entries are 
displayed in an outline form as they were defined in the domain. Thefirst column in the table fists the names of customer 
groups or customers, while the remaining columns contain the total sales data tar that customer. A split line in the table 
divides historical and Forecast Data 146. The time spans tor historical and Forecast Data 146 can be specified by the 
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user. 

Customer groups may be e>?>8iid9d or collapsad ^ 
Product Tafate 

Hie bottom table displays all products carried by the selected customer (group). Seles data tor each product shown 
«^ 7L be ^*«**)aps«l by double dieting on a product name, The entries 

beneath each product include actual orders, forward orders, and orientation orders. As wflh the Customer Table, the 
^.sspfcttoshow^ 

historical and Forecast Data 14a Promotion periods are highlighted on the display. 
Total Columns 

On the right side of the Product table is three columns which can display a selection of user-defined totals from the 
following choices: YTD Year to date; YTG Year to go; YTDL Year to date last year; YTDB Year to date budget- YTGB 
Year to go budget and L12M Last 12 months. 9 * ° 

General Features 

Promotions periods are displayed highlighted The impact of promoted verses unpromoted sales can be displayed 
f e ^?!5 r ° fycn cetls - Tn8mix (weentaae can be used to disaggregate a forecast generated at the aggregated 
level of the customer or customer group. Disaggregation can also be done based on the total tor the year and some 
user defined seasonality factors when the menu option Disaggregate Total year* is chosen. Time series of user defined 
"tearing indicators' can be displayed for reference and forecasting purposes. 

Top-Down Forecast 

As would be expected, the Top-Down (TO) forecast screen (see figure 57) is similar to the Bottom-Up Forecast 
screen, except that the interface is arranged tor product-driven forecast operations On the TO screen the Product table 
appears at the top, while the Customer table appears below it Data display options and forecasting tools for TD oper- 
ations are accessed from the TD screen menu and subsequent dialog boxes. 

Product Table 

The Product table displays the list of products from the selected domain. Only those entries which are strictly prod- 
uct-onented are shown in this table, and are displayed in an outline form as they were defined in the domain. The first 
wlumnin the table lists the names of product groups or individual products, while the remaining columns contain the 
sales data for that product aggregated at the appropriate level. A split line in the table divides historical and Forecast 
Data 146. 

Thenthe user selects a product group or product from the Product tabtatho flstof custbl neni carry irigt he prod- 
uct(s) is displayed in the Customer table as described below. Product groups may be expanded or collapsed by double 
cficKng their names in the Product column entry. wwuapswoyaouwe 



Customer Table 



The bottom table displays all customers who carry any of the products selected in the Product table. If a customer 
cames all of the selected products, it is displayed in a focused font, otherwise it is shown in normal font Sales data tor 
each customer is shown. The entries beneath each product include actual orders, forward orders, and orientation 
orders As with the Product table, the customer table is split to show both historical and Forecast Data 145 The user 
may specify the position in the time series for the historical and Forecast Data 146. Promotion periods are highlighted 
on the display. 



Total Columns 



On the right side of the Customer table are three columns which can display a selection of user-def ined totals from 
the following choices: YTD Year to date: YTG Year to go; YTDL Year to date last year; YTDB Year to date budoet YTGB 
Year to go budget; and L12M Last 12 months. ^* 
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General Features 

Promotion periods are displayed highlighted. The impact of promoted verses unpromoted sales can be delayed 
separately in drop-off ceOs. The ntix percentage can be used to disaggregate a forecast generated at the aggregated 
level of the customer or customer group. Disaggregation can also be done based on the total tor the year and some 
user defined seasonality factors when the menu option "Disaggregate Total Year" is chosen. Time series of user defined 
"leading indicators" can be displayed for reference and forecasting purposes. 

Sales Promotion Analysis 

The User Interface that supports Sales Promotion Analysts is built around the promotion calendar. The promotion 
calendar shows the list of all the past and planned promotions for the set of products art customers defined by the 
' selected domain. 

For each promotion the following is displayed in the promotion calendar : darting date of the promotion; end date 
of the promotion; promotion type; promotion dass; product being promoted; customers supporting the promotions- pro- 
motion intensity; and impact of the promotion. 

When the user cfo*s on the promotion calendar button on the toolbar, the promotion calendar Main Display Win- 
dow is displayed (see figure 58). 

The user can select one or several promotions in the promotion calendar. Fa these promotions the user can per- 
form the operations discussed below. Display shipment and POS Data 1 38 in table formats similar to the one used in 
BUandTD forecasts. Compute the promotion impact for past promotions. Estimate the inpact of future promotions. 
Display graphically the impact of the promotions on safes. 

If the user wishes to view the customer-product tuple (domain) that promotions are displayed for, or wishes to limit 
the promotions shown by choosing what Promotion Type. Promotion Class and Promotion Intercity he wishes to ana- 
lyze, the Promotion Selection Wizard may be invoked. The user selects the customer-product pairs that analysis is to 
take place on and can limit the selection by choosing what Promotion Type. Promotion Class and Promotion Intensity 
he wishes to analyza When the OK button is clicked, the Promotion Calendar dialog box is populated with all promo- 
tions that match the selection criteria (See figure 59). 

PSI Frame 

The PSI main screen is a work area where the user can experiment with different Production. Inventory and Sales 
figures and see the effects caused by these changes to eventually converge to the most desirable PSI plan 190 The 
Main PSI Screen (see figure 61) initially shows the Production. Inventory and Sales for all of the products in the user 
selected domain. The figures for all of the products are aggregated together and shown. The user may also select any 
individual product in the aggregation and show the numbers far this product alone. This can be done by choosing the 
desired product number from the Product selection combo box located near the top left of the screen. The first choice 
in the combo box is always All Products to allow the aggregation of all products to be shown. The user may change the 
products being analyzed by selecting a new set of products from all available products. This may be done by selecting 
q n ew doma in. - — 



Directly following the Production (P). Inventory (I) and Sales (S) lines are Temporary P. S and I fines (see figure 60) 
This is a work area where the user may copy and experiment with the real P. S or I figures and modify them to aeate 
new Scenarios 78. Copy and Paste are enabled on this form so the user may copy the original numbers to the work 
areas. The user may also copy a time series from another part of the DSS 1 0 or a separate application to the temporary 
Jfeestttfoughcopy andpaste. Lastly, the user may load data from a saved scenario to the temporary lines on the^formr 
The individual cells that comprise the temporary work area may be manually edited by the user by clicking on the 
desired cell and changing the value in the cell. 

Also present on the work area of the form are Top-Down, Bottom Up. Customer demand information, a Top-Down 
minus Bottom Up fTO-BU) and Top-Down minus Sales (TD-S) lines. These lines give the user different and useful views, 
into the planning data under analysis. These fines are calculated based on the values in the temporary R S and I fines 
of the form 



The last column <f splayed on the screen is a sum of the data displayed on the screen for the current year. This col- 
umn remains on the screen and does not scroll left to right as other columns are being scrolled horizontally The titles 
of the various horizontal lines of data also does not scroll, but the data series may be serened forward or backward 
through time. The month and year associated with the data are displayed immediately above the working area of the 
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PS I Reconciliation 

While working with the data in the temporary R I and S Ones, the user may want to make sure the three lines are 
always consistent This may be accomplished by selecting PSI Reconciliation on the Options menu (see figure 62). 
s When selected, a check mark wifl appear next to this menu choice and the PSI screen will reconcile all data input 
by the user. PSI Reconciliation 170 functions by updating one line of data based on a new value input into a different 
lino. The user has control over which line gets updated by setting the PSI reconciliation order. 

The user sets the PSI reconciliation order by choosing PSI Reconcffiation Order from the Options Menu (see figure 
61). This wfll open the PSI Reconciliation Dialog Box (see figure 62). From this window the user can choose which 
to line(P. S or I) is updated when the selected One is modified by the user. In the example shown, the I line would be 
updated when the Production line is changed. 

Capacity Checking 

is While working with the Production. Inventory and Sales figures, the user may wish to check the capacity of the 
existing production resources to determine if the current plan is feasible. This is (grown as capacity cheddng. This can 
be accessed by clicking the Check Capacity button on the Options menu group on the main PSI screen The main 
capacity checking dialog box will then be displayed (see figure 63). 

The Options tab allows the user to select the desired plant location and the feature of interest and pkfc the existing 

20 lines that may produce the products with the selected featura The user may remove selected products from the Ost of 
products that he wishes to analyza The user may select the Production resources he wishes to analyze from the Gst of 
available production resources. The user may select the key components of the products that he wishes to analyze. The 
user may change the options before performing capacity checking to restrict the scope of the Model Engine 20. and 
after checking capacity for viewing purposes. 

25 The results tab shows (see figure 64) the results of the capacity checking. For all products selected, a production 
plan is displayed, and at the top of the screen, whether or not the plan is feasible is indicated. The capacity checking 
may be viewed product by product or by product group 

The production resource tab (see figure 65) is used to show the available capacity tor the selected line for two 
months. H this line has enough capacity, it is indicated at the top of the screen to be feasible. The user can also see how 

30 much capacity remains or how much more is needed by looking at the Over and Under lines. 

The Key Components tab (see figure 66) is used to view the important components required to assemble a f inal 
product and check whether, using the current figures, there is sufficient quantity of these components. If too much pro- 
duction requiring one key component is scheduled and the part will run out then the key component is indicated as 
infeas&Je. 

& The Bill of Material tab (see figure 67) allows the user to see which components are used in which products. By 
selecting specific components, the user can see which products use the compo nen ts. 

The Alternative Components tab (see figure 68) allows the user to see components that may be substituted for 
other components during production. The user may view the fist in two ways. By selecting Product, the user can see the 
components that are used to assemble the product and any alternative tor the components. By selecting Component, 
-40- the user can see specific component s and any alternative parts that exist ~ 

The Resource Requirement tab (see figure 69) allows the user to see the projected production plan tor a selected 
assembly line and product feature type. The user may view this by selecting a line then a product group that may be 
produced on the One or by selecting a product group then a line and viewing the schedule tor the selected product 
groups 

45 

Key Components Selection 

To analyze production of a product the user must work with the components that are used to build the product. The 
user does not need to exhaustively analyze all compwents, butjust a s ubset o f the components. These are the m ajor 
so ~ components of the product and are usually referred to as the Key Components. Which components are considered key 
may change over timet so the user must have a way of selecting the current key components. This task is performed by 
using the Key Component Selection dialog box (see figure 70). 

The Key Components column of the main display area indicates whether the component is a key component All 
key components are also shown in a list at the right of the dialog box. The user may change the setting of a component 
55 or multiple components by selecting them and clicking the Key Components button to set them to be key or Not Key 
Components to make the components not key. The user may sort the components so all key components are shown at 
the top of the list by cficWng the Sort Components button. 

The second column of the main display area is a total for a selected range of months The default is for the entire 
year. The user may select a different range by using the mouse to highlight a range of months and clicking the Ordered 
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Based on Months button. This will retota! the column for the selected range of months and change the caption for the 
column to indicate the month range selected. It wifl also sort the Cst of components to 
availability over usage to least availaMty over usage over the selected time period. 

The many features and advantages of the invention are apparent from the detafled specification and thus, it is 
intended by (he appended claims to cover all such features and advantages of the invents 
Spirit and scope of the invention. Further, since numerous modifications and changes win readily occur to those staled 
in the art. it is not desired to emit the invention to the exact construction and operation illustrated and described and 
accordingly all suitable modifications and equivalents may be resorted to. fading within the scope of the invention.' 

Appendix A 

Database Specifications for Manufacturing Supply Chain 

The following are the specification* of the data tables for the 
manufacturing supply chain. 

Aggregate Production Plan Data 

^^!5 e ? ■J^JPEZE? Pr0ducti0n f « <** P"*»« and re.ourca 



Field Identifier 


Pield 
Type 


Description \ 


APPReaderZD 


Long 


APP Header identifier (see aggregate 
production plan Header table) 


Time Period 


Date/Time 


Time period number 


SupplyOrderZO 


Text 


Supply order pegged to (if 
available) 


Quantity 


Double 


Number of units of production 


PrcposedChange 


Double 


Recommended change in the planned 
quantity (to store changes between 1 
regeneration of APPa) H 



-40- 
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Aggregate Production Plan Header 

Header file for defining the Product X Resource X Time resolution* and 



5 



20 



valuea for various agi 


gregate production plans. 


| Field Identifier 


Plaid 

Type 




H APPHeaderZD 




APP Data Seriee Identifier 


| APPXD 


Text 


Identifier for an aggregate 
production plan 


I ResourceResolution 
1 


Text 


Resource Resolution: R- Resource, O- 
Group, N-Hode 


1 Resource XD 


Text 


Resource associated with an 
aggregate production plan 


I Product Resolution 


Text 


Product Resolution: P- Product, 0- 
Qroup 


Product XD 


Text 


Product associated with an aggregate 
production plan 


. TlraeResolution 


Text 


d cor oay; w cor waeJc; F cor Bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


| DateCreated 


Date/Time 


Date when the aggregate production 
plan was created (baaed on the time 
resolution) 


1 Scenario Data 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this 
header participates 



Budget Data 

Data for budgeted coats and revenues 



40 



H Field Identifier 


Field Type 


Description | 


R Budget Header ID 


Long 


Budget header identifier 




H TimePeriod 


Date /Time 


Time period number 




| TargetRevenue 


Double 


Target revenue in $ 




| BudgetCost 


Double 


Allocated cost in $ 
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Budget Header 

Header file for defining the Product X Resource X Customer X Time 
resjolutjions^notjOL^ne^ 



Field Identifier 


Field Type 


Description mm^m^^™^ 


BudgetHeaderXD 




Identifier for the BudgetHeader 


ProtfuctRe solution 


Text 




Product ZD 


Text 




Customer Resolution 


Text 


0 for Customer Group, A for all 


Customer ZD 


Text 


Customer asaoelafcad wifcli thm hurfMt 1 


Re sourcaRa solution 


Text 


Resource Resolution* R- Resource, 0- 
Group, N-Mode 


ReaourcelD 


Text 


Resource associated with the budget 


TUB6KN01UC IvD 


Text 


M for week; P for bi-weekly; N for 
monthly; B for bi-monthly; Q for 
quarterly; and A for annually 


Calendar IP 


Long 


Pegged to a predefined calendar 


DateCreated 


Date/Time 


Date of creation for this header 


ScenarioOata 


Boolean 


Yes if it is scensrio data. Ho 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this 
header participates 


Calendar 

Predefined calends re 


to peg the various data to 


Field Identifier 


Field Type 


Description 


Calender ID 


Long 


Unique calendar identifier 


Date 


Date/Time 


Julian Calendar Date 


Daytfo 


Double 


unique number for a day in the 
calendar year (typically 1 through 
365) 


tfeeJcNo 


Double 


Unique number for a week in the 
calendar year (typically X- through 52) 


BiWeekNo 


Double 


Unique number for a bi-week in the 
calendar year (typically 1 through 26) 


MonthNo 


Double 


Unqiue number for a month in the 
calendar year (typically l through 12) 


BiMonthN© 


Double 


Unique number- for a- bi- month in the 

calendar year (typically 1 through 6) 


QuarterNo 


Double 


Unique number for a quarter in the 
calendar year (typically 1 through 4) 


Holiday Indicator- — 


-Boolean 


To indicate whether it is a- holiday or - 
not 
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Component 

Data related to co 



of the 



| Field Identifier 


Pield Type 


Description 


ComponentID 


Text 


Component IP in the planning BOM from 
corporate master (e.g. 3317307) 


CoBjponentHnmo 


Text 


Hame of the component 


HinPackQuantitv 


Double 


Minimum pack quantity 


Physical Parameter 


Text 


Physical dinenaiona for the 


CompCategory 


Text 


S for Off-the-shelf; C for 
Customised 


Packaging Instruction 


Text 


Special packaging requirements 



Equivalence of the key co 


mponence to produce different products 


| Field Identifier 


Field Type 


Description f 


1 ProductID 


Text 


SHU number jj 


PrimaryComponentZD 


Text 


Primary component identifier 8 


AlternativeComponentID 


Text 


Alternative component identifier fl 


Quantity 


Text 


Number of components ■ of the | 
Alternative Component that can 
substitute for one unit of the 
Primary component to product 
ProductID U 



Component Requirement Data 



Field Identifier 


Field Type 


Description 


CompReqHeaderlD 


Long 


Identifier for the component 
requirement header 


TlmePeriod 


Date/Time 


Tims period number 


Quantity 


Double 


Number of units during the time. period- 


Proposed Changs 


Double 


Proposed Change in required quantity 



114 



EP0770967A2 



Component Requirement Header 
Reader file defining the Component 
vari ous component requirement data 



10 



15 



20 



X Time resolutions and values for 



Field Identifier 


Field Type 


Description 


CompKeqHeadexXD 


Long 


Component Requirement Hudar 
Identifier 


Component n> 


Text 


Component associated with an 
components requirements plan 


BONZD 


Text 


Unique identifier for BOM 


DateCreated 


Date/Time 


Date whwi fcha emimunimt ■ ■■ ■ I ram«nf n 

plan was created (based on the time 
resolution) . 


TimeRe solution 


Text 


D for day; N for week; F for bi- 
weekly; M for monthly; 8 for bi- 
monthly; 0 for quarterly; and A for 
annually 


Calendar ID 


Integer 


Pegged to a predefined calendar 


APPID 


Text 


Pegged to an aggregate production plan 
(if warranted) 


ScenarioOata 




Yes if it is scenario data, NO 
otherwise | 


ScenarioCounter 


Byte 


number of scenarios in which this 1 
header participates I 



Component Supplier 



1 Field Identifier 


Field Type 


Description 


CompSupplierlD 


Text 


Unique identifier for the component 
supplier 


SupplierName 


Text 




1 PaymentTerms 


Text 


Bxample: Net- 60 


StreetAddreaa 


Text 


Street Address 


StatelD 


Text 


Kame of the State 


PostalCode 


Text 


Postal code 


Country 


Text 


Name of the country 



so 
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Component Supply Contract 

Data associated with the component supply contract 



Field Identifier 


Field Type 


Description . 


SupplyCont ract ZD 


Text 


Identifier for the supply contract 


ContractDate 


Text 


Date of the contract 


HomialLeadTime 


Text 


negotiated nominal lead time for a 
defined average quantity 


UnitPrice 


Double 


Negotiated unit price of the component 


QtyDis count 


Double 


Percentage of discount if the quantity 
is above QtyforDlscount 


ucyxoruiivoujib 


Ann HI m 


Minimum size ox tne omer to quality 
for the quantity discount . 


MinOrderQty 


Double 


Minimum quantity that can be ordered 
from the supplier H 


Component Supply Node 
Data associated 'with 


the component 


supply node 


H Pield Identifier 


Field Type 


Description 


| CompSupplyNode ID 


Text 


unique identifier for the supply node 
(e.g., CVTCablnetNodel) 


| CompSupplierlD 


Text 


Identifier of the component supplier 


AvgSupplyLeadt ime 


Double 


Average lead time to supply the | 
components (from the time of order) H 


SupplyCont ract ID 


Text 


ID for the Supply Contract (See 1 
Component Supply Contract Table) II 


PreferredCarrier 


Text 


Preferred transportation carrier for J 
shipping (e.g., FEDEX) 1 


Customer 

Ojttit for individual c 






Field Identifier 


04*1*1 ffii mm ■ 

Field Type 


Description 1 


Customer ID 


Text 


Customer- from corporate customer 1 






master (e.g. BestP) *i 


ShlpToLocation 


Text 


Specific customer location (e.g. DC1) 


DemandNodelD 


Text 


The demand node this customer is 
associated with 


CustomerName 


Text ~ 


Name of the customer 


Address 


Text 


Street address 


State 


Text 


Name of the state 


PostalCode 


Text 


Postal- code (Zipcode for* domestic) 


Country 


Text 


Name of the Country 
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Customer Group 

Data for cugtomer groups 



Field identifier 


Field Type 


Description 


CustomerGroupXD 


Text 


Identifier for the customer croup 


CustomerGroupHame 


Text 


Descriptive name of customer group 
<e.g. # Stereo CTV) 


CuatoowjrGroupTag 


Text 


Organisational entity who defined the 
build criteria for the customer group 
(e.g. Marketing) 




Text 




ScenarioGroup 


Boolean 


yea if this is scenario group; No 
otherwise 


Customer Group Defini 
Table that identifies 
and customers 


tion 

the parent-child relationship between customer groups 


\ Field Identifier 




Description 


CuatomerGroupID 


Text 


Heme of the customer group 


CuatomertP 


Text 


Heme of the member customer (or 
cue tomsr^groug^ 
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Customer Orders 

Data for actual cmtoror order* 



5 



10 



70 



25 



30 



1 Field Identifier 


Field Type 


Oeecriptien | 


CuetomerOrdcrld 


Text 


ZD for the actual customer order (e.g. 1 
pcec type 1 orders) * i 


LineltemXD 


Text 


Line item within the order "fl 


CustcmerOrderRefHe 


Text 




Customer ID 


Text 




ShipTolo cation 


Text 




Product ZD 


Text 


Product associated with the order 






Pegged to a calendar 


TlmeResolution 


Text 


D for day; W for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


OrderSetryOete 


Data/Tina 


Expressed in terms of the calender and 
time resolution 


RequestedDate 


Date/Time 


Expressed in terms of the calendar and 
time resolution 


DueOata 


Date/Time 


Expressed in terms of the calendar and 
time resolution 


ShipDate 


Date/Time 


Expressed in terms of the calendar and 
time resolution 


DellveryDate 


Date/Tine 


Expressed in terms of the calendar and 
time resolution | 


Quantity 


Double 


Quantity of the order 




Memo 


Such as value added services 
associated with the order 



Customer Product Resource Relationship Matrix 
35 Table that Identifies the customers. Product and Resources that have 
pairvise relationships 



45 



| Field Zdeatif ier 


Field Type 


Description 


ProductResolut ion 


Text 


Resolution of the product; P for 
product. 0 for product group 


Product ZD 


Text 


Identifier for the product or product 
group 


CustomerReeolut ion 


Text 


Resolution of the customer: C for 
customer, Q for customer group 


CustomerZS . ^ 


Text 


Identifier for the customer or 
customer group 


DatatypeZD 


Text 


POS Data, Top Down Forecast. Bottom Up 
Forecast 


ResourceResolution 


Text 


Resolution of the resource: R for 
resource, Q for resource group 


SeaourcelO 


Text 


Identifier for the resource or 
resource grouo^ 
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Demand History Data 



Field identifier 


Field Type 




DemendHl stHeaderlP 


hong. 




TimePerlod 


Date/Time 


Time period nnnbtr 


DeteandQty 


Long 


Demand Otiaatltv f 


Demand History Reader 
nwuir tui oerininfj 
various demand hi at ox 


the Customer 
lee 


X Product X Tine resolutions & values for 


Field Identifier 


Field Type 




OemandHlstHeaderXD 


Long 




Product&esolution 


Text 


P for product i O for Product ftvrnm. & 


Product ID 


Text 


Product associated with demand history 


CustomerReeolution 


Text 


8 for cue t ooer ship toy C for 
customer; 0 for customer group/ M for 


Customer ID 


Text 


Customer sssociated with demand 


TlmeReaolut ion 


Text 


0 for day; W for week; F for bi- 
weekly; N for monthly; B for bi- 
•oathly; Q for Quarterly; and A for 
annually. 


Calendar ID ! 


Integer 


Pegged to a predefined calendar 


OateCremted 


Date/Tine 


Date of creation of the header 


ScenarioData 


Boolean 


Yee if it ie scenario data. Ho ) 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this 



Demand Bode 

Data aaaociated with 



the demand node 



Field Identifier 


Field Type 


Deacriptioo j 


DemandHodelO 


Text 


Unique identifier for the demand node 
(e.g., SEAM or a region) from the 
enterprise point of view 


DemandRodeHame 


Text 




Comment 


Text 




Demand Orientation Data 

Data associated with the demand orientation for th* nr^,^ <a—+4,*-* 


toe header 






Field Identifier 


Field Type 




OrientationBeaderlD 


Lone 




TimePerlod 


Date/Time 


Date when the order is projected as 
required 


Quantity 


Double 
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Demand Orientation Header 

Header file defining the Customer X Product X Time resolution* and values 
for various demand orlentationa 



Field Identifier 


Field Type 


Description 


OrientationReaderXD 


Long 


Orientation Header Identifier 


CuatomerResolution 


Text 


S for customer ship to; C for 

CUBtQflMr t Q fflf wiafwBwy a rnim • 1* 

/ w iw* IpIwwbhih 3* uu|i / n SOr 

market; A for all customers 


CustomerlD 


Text 


Customer identified with the place 
keeping order 


Products solution 


Text 


P for product; 0 for produce group; A 
tor all products 


Product ID 


Text 


Product associated with the 
orientation order 


TimeResolutien 


Text 


O for day; W for week; F for bi- 1 
weekly; K for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Long 


Pegged to a calendar 


DateCreated 


Date/Time 


Date the header was created 


ScenarioData 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


number of scenarios in which this 
header participates 1 



Domain 

aser and domain description for various domains 



| Field Identifier 


Field Type 


Description 1 


Domain ID 


_Lon« 




DomainName 


Text 


The name of the domain 


DomainOwner 


Text 


The owner of the domain 


Domain Definition 
Domain definitions in 


terms of product « customer and resource groups - 


Field Identifier 


Field Type 


Description 


Dome in ID 


Long 




ProductResolution 


Text 


P for product; 6 for Product Group; A 
for all products - 


Product 


Text 




CustoraarJle solution 


Text 


C for customer; Q for customer group; 
M for market; A for all customers 


Customer 


Text 
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Feature Choices 

The various unique values tor the different product features-generated 
batch basis 



on a 



1 Field Identifier 


Field Tvpe 


Description n 


ProduetType 


Text 


The Evm nf fcha Product ^K>» *-U*mm. H 

features belong to 1 


Feature 


Integer 


Feature of the Product J 


Choice 


Text 


Sane of the Feature possibility D 


Forecast Data 

Data associated with 

forecast header 


forecasts for 


the product- cue tomere identified in the 


Field Identifier 


Field Type 


Description 


FcatBeaderlD 


Long 


Pegged to the Forecast Reader' Table 


TimePeriod 


Date/Time 


Time period number 


Forecaetvalue 


Double 


Forecast data value 


ForecastCV 


Double 


Coefficient of variation of forecast 



Forecaat Header 

Header file defining the Customer 
various forecasts 



X Product X Tine resolutions a values for 



Field Identifier 



FcstReaderlD 



Froductfteaolution 



ProductIP 



CustomerReaolutioa 



Customer ID 



TlmeReeolutlon 



Calendar ZD 



DateCreated 



ForecastType 



ForecaatAssumptions 



ForecaatOwner 



ScenarioData 



Scenar ioCount er 



Field Type 



Long 



Text 



Text 



Text 



Text 



Text 



Integer 



Date/Tin 



Text 



Text 



Boolean 



Byte 



Description 



Forecaet Header Identifier 



P for Product, 0 for Product Group, A 
for all Products 



Product aesoclated with forecast 



8 for Ship- to, c for Customer, o for 
Customer Group, a for all Customers 



Customer associated with forecast 



D for day; w for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 



Pegged to a predefined calendar 



Date when the forecast was created 
(based on the time resolution) 



B for bottom- up; T for top-down 



Asa^jiBptions^-ssocia^d^^^he - 
forecast 



Author of the forecaat 



Yes if it is a scenario data; No 
otherwise — 



Number of scenarios in which this 
^eader^^particioa^es^^^^^^ 
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Freight Rate 

Table that summarizes the various freight rates 


5 


1 Field Identifier 


Field Type 


H 

Description . j| 




PreightRateTafeleXD 


Text 


Freight rate table identifier 




PreiohtDescriotion 


Text 




10 


HaxWeiaht 


Double 


it«H mm Mfiiaht limit (a a 

it* * iii mil >«A<|uv ••iuAb |0«^t (SUCK 

capacity) 




MaxCube 


Double 


Maximum volume limit 




Height Category 


Text 


e.g. 0-l001b, 100-SOOlb, etc. 


15 


Mileagecategory 


Text 


e.g. less than 100 miles, leas than 
500 miles, etc. 




MlnimumCharge 


Double 


Minimum charge associated With a trip 




StdCost 


Double 


e.g. $ per hundred weight charge for 

TTL «n (4 < J mi 1 m 4r\<w TT 
UU XOr Tb 


20 


BcoaomyCost 


Double 


e.g. for fedex economy rate 




PremiumCoat 


Double 


e.g. for fedex next day service 


Inventory Data 

Inventory data for Items (products 


or components) identified in the header 




Field Identifier 


Field Type 


Description 1 




Invent oryHeader ID 


Long 






TimePeriod 


Date/Time 


Time period number 


30 


OnBandlnventory 


Double 


On- hand available inventory for 
allocation 




OnOrder Inventory 


Double 


On- order inventory 




BackOrder Inventory 


Double 


Back- ordered inventory 


35 


InTransit 


Double 


In- transit quantity 




Reservedlnventory 


Double 


Reserved inventory on* hand but 
available for allocation only in case 
of emergency 




40 

45 









50 



55 



122 



EP07709S7A2 



Inventory Header 

Header file defining the item (Product or Component) X Tine ft and values 



10 



is 



\ Field Identifier 


Field Type 


Description j* 


ZnventoryHeaderZD 


Lonn^ 




Invent orysode ID 


Text 


Identifier for — invwnfnn/ i«*m4 4»_? 

warehouse 


Znventorycontrolxo 


Text 


Identifier for inventory control 


itemiD 


fay* 


M 1 — *t .. - w& 

Froouct iten id 


I tem&Aaolufc ion 




Item Resolution: C for Component* P 
for Product/ 0 for Product Group and A 
for All 


TineAeaolution 


Text 


D for day; w for week; F for bi- B 
weekly; M for monthly; B for bi- | 

monthlv: O for ouirttrlvf mnA A fnr I 

annually. | 


Calendar ID 


Integer 


Pegged to a predefined calendar | 


I MinXnventoryLevel 


Double 


Minimum inventory level for the item 


| MaxXnventoryLevel 


Double 


Maximum inventory level for the item 


DateCreated 


Date/Time 


Date the inventory header was created 


ScenarioData 


Boolean 


Yes if it is scenario data, No 
otherwise 


ScenarioCounter 


Byte 


Number of scenarios in which this tt 
header participates 1 



Inventory Node 



Field Identifier 


Field Type 


Description 


Invent oryNode ID 


Text 


Unique identifier for the inventory 
node (e.g., Arden Warehouse 2 ) 


FacilitylD 


Text 


Physical Facility identifier 


InventoryCategory — 


-Text 


Component- or-FO- Enterprise 


Invent ory£che Ion 


Double 


l or 2 


InventoryKodeName 


Text 


Name for the inventory node 


ServiceLevel 


Double 


Service level for the inventory node 1 


Address—' — 


Text 


Address for the inventory node 


StorageCapacity 


Double 


Physical storage capacity of the 
inventory node (in cubic feet for 
example) 
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Inventory Parameters 

Data for the inventory control parameters 



5 



20 



Field identifier 


Field Type 


Description 1 


1 


Twvnf rtrvPnwt rftl TP 

V IUIWvA JVUWk «V*Mf 


Text 


Identifier for inventorv control 
parametere : Assume Inventory 
planning • inventory cons so* 




sez e tys tocxrac tor 


DOUDIO 


serety stocx z actor 


* 


Targets ervicel^vel 


DOUDie 


Target service, level 




poxicyrype 


Text 


policy type: sb, Kin/Max # wk, etc. 




MinXnventoryFactor 


Double 


Minimum inventory factor (e.g., in 




MaxXnventoryFactor 


Double 


Maximum inventory factory (e.g., 
in terma of weeks of aalea) 




MinOrderQtyFactor 


Double 


Minimum order quantity factor 




CaxryChargeFactor \ 


Double 


Carrying coat factor 




OzderCnargeFactor 


Double 


Ordering coat factor 




InventoryClaaa 


Text 


Inventory classification 




Repleniahmant 
Frequency 


Double 


Frequency of repleniahment w.r.t. 
the time resolution in the header 




Market Data 

Data for the market defined in the 


header 




Field Identifier 


Field Type 


Description 1 


MarketHeaderXD 


Long 


ID for market header (aee Market 
Header table) 


TimePeriod 


Date/Time 


Time period 


MarketShare 


Double 


Percentage of share held by the 
company 


Conaume r Demand 


Double 


Total demand quantity 


AverageSellingPri.ee 


Currency 


Average Unit Price of the product 


DemandForecast 


Double 


Forecasted demand 



4$ 



— so- 
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Market Header 
Header for defining 



10 



13 



20 



| Field Identifier 


Field Type 


Description p 


MarketHeaderlD 


Long 




MarketDef initicnXD 


Text 


unique laentirier cor a market -(a. a. . 
PTV-S) * 


MarketName 


Text 


Market Description (e.g. Projection TV 


OataScope 


Text 


Suitable tagi Brand name (e.g., Sony) 
or industry-vide 


DataSourcelD 


Text 


Source of market data (e.g. jjmsgj 1 


TlmeResolution 


Text 


D for day; w for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


ProductReaolution 


Text 


P-Product. PO-Product Group, A-All 


Product n> 


Text 


Identifier for the product 


CuetomerReaolution 


Text 


C- Customer, OQ-Cuetomsr Group, A- All 


CustomerlD 


Text 


Identifier for the customer 


DateCreated 


Date/Time 




SeenarioData 


Boolean 


Yes if it is scenario data; NO 
otherwise 


ScenarioCounter 


Byte 


number of scenarios in which this 
header participates 



Material Delivery Schedule Data 





Field Identifier 


Field Type 


Description 






MDSHeaderlD 


Long 


Identifier for the Material Delivery 




40 


DeliveryDate 


Date/Time 


Material Delivery Date 






Quantity 


Double 


Number of units of material delivery 





50 



55 



125 



EP0770 967A2 



Material Delivery 
Header file 
for various 



Header file defining 
material 



• Header 

the co m p one nt X Supplier X Time resolutions 6 valuae 
delivery schedules 



10 



13 



20 



Field identifier 


no* a Type 


Description 


MDSBeaderXB 




Identifier for the Material Delivery 
Schedule Header 


ComponentSupplytZod 
eZO 


Text 


Identifier for component supply node 


Supplier ID 


Text 


Supplier associated with a Material • 
Delivery Schedule 1 


Timefteaolutlcn 


Text 


D for day; w for week; F for bi- 
weekly; M fox monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


Daeecreated 


Date/Time 


Date whan a Material Delivery Schedule 
was created (based on consistent tins . 
units} 


ScenarioOata 


Boolean 


Yes if it is scenario data. No 
otherwise 


ScenarioCounter 


Byte 


Hunter of scenarios in which this 
header participatea 


Planning BOM 

Imploded Bill of Material uaed for Planning 


H Field Identifier 


Field Type 


Description 


U BOM ID 


Text 


Unique identifier for the planning BOM 
(defined external to the DS8 database) 


1 Component ZD 


Text 


Unique component identifier 


fl Product ID 


Text 


SXD number 


\ Quantity 


Double 


Number of components used in SXD 



40 



POS Data 
Point of Sale data for 



the customer' 



SO 



products identified in the header 



Field Identifier 


Field Type 


Description 


FOSReaderlD 


Long 


POS Reader Identifier 








Time Period 


Date/Time 


Timer period number (beginning of 
the time period) 


SellThrough 


Double 


Sale to end user 


Shipments 


Double 


.Shipments from the customer DC to 
the stores 


-Receipts— — 


Double 


Shipmants-f roo- the- vendor- (e . g. 






pcec) to the customer dc 


DClnventoryStatue 


Double 


Onhand inventory at the ship to 
location (customer dc) 


Store ZnventoryStatus 


Double 


Aggregate onhand inventory of stores 
served by the customer ship to 
location (e.g. dc) 


| StoresOnOrderQty 


Double 


On order quantity from the stores to 
the customer dc 
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POS Header 

Header file defining 
various POS Pete 



the Customer X Product A Tine resolutions 4 values for 



5 


Field Identifier 


Field Type 


Description 






POSEeaderXO 


Long 


Identifier for the Point of Sales 
Header 




10 


Customer Resolution 


Text 


Cuetoaer Resolution: S for Customer 
Shipto, C for Customer, 0 for Customer 
Group, A for ell 






CustoaerXO 


text 


Should be e valid customer group or a 
null set (e.g., selling floor) 




15 


ProductReaolution 


Text 


Product Resolution: P for Product. 0 
for Product Group, A for all 




Product IO 


Text 


Product associated with the POS Data 




20 


TlmeJLesolution 


Text 


D for day; W for week; F for bi- 
weekly; N for monthly; B for bi- 
monthly; 0 for quarterly; and A for 
annually. 




Calendar ID 


Lone/ 


Pegged to a specific calendar 






DateCreated 


Date/Time 


Date the POS Beader was created or 
modified 




25 


ScenarloData 


Boolean 


Yes if it is scenario data; No 
otherwise 




ScenarioCounter 




Number of scenarios in which this 
header participates 




Product 

30 Data for end products 








Field Identifier 


Field Type 


Description 






Product ZD 


Text 


SKU from corporate item master (e.g. 
RR1330W) 




35 


ProductHame 


Text 


Name of the Product 






FroductCategory 


Text 


Product Category 






Featurel 


Text 


Example: Brand 






Feature! 


Text 


Example: Screen size 




40 


Feature3 


Text 


Example: Audio: M-Nono, S- Stereo, P- 
Prologlc, D- Dolby Proloo/lc 






Feature* 


Text 


Example: Subtype 






Features 


Text 


Example: Cabinet type 






Feature*— 


_Text 


Example: Chassis type 






ProductDescription 


Text 


Description of the product 






SXDSlse 


Double 


Number of product units in a SKD 

(e.g.il 






I FhysicalDimenaians 


Text 


Height X Depth x Width 




- 


1 weight 


Double 


Height of the SKD 
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Product Feature* 

The feature lift of the 



10 



15 



Field Identifier 


Field Type 


Description . 


ProductCaeegory 


Text 


Product Category 


FeatureHumber 




Feature Field Number 


FeatureHane 


Text 


Feature Name Description 


Product Group 

Data for product grou 


PS- 




Field Identifier 


Field Type 


Description 


ProductOroupII) 


Text 


Identifier for the product, group 


ProductaroupJtane 


Text 


Descriptive name of product group 
(e.g. i9Stereo) 


ProductGroupTag 


Text 


Organisational entity who defined the 
build criteria for the product group 
(e.g. Marketing) 


ScenarioGroup 


Boolean 


Yes if this is scenario group; NO 
otherwise 



Product Group Definition 

Table chat identifies the parent-child relationship between product groups 
and products 



Field Identifier 


Field Type 


Description 


Produc tGroupPar ent ID 


Text 


Identifier for the product group 
that is the parent 


ProductGroupChlldID- 


Text 


Identifier for the product group or 
product that is the child 



40 



Production Accommodation Matrix 

Table that identifies alternative production resources for producing 
various products 



| Field Identifier 


Field Type 


Description 


Product ID 


Text 


Identifier for the Product 


PrimaryResourcelD 


Text 


Identifier for the Primary Production 
Resource 


Alternative Resource 

-ID 


Text 


Identifier for the Alternative 
Production Resource 1 


Quantity 


Double 


Number of units of Alternative 
Resource that can substitute for 
Primary Reaource to Product 



so 
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Production Capacity Data 

Production Capacity Data of the production resource- identified in the 
header 



5 


Field Identifier 


Field Type 


Description 




ProductionCapaeity 
Header ZD 


Long 


Production Capacity Header ZD (See 
FroauctiQS capacity seaaer Table) 


10 


TiaePeriod 


Date/Time 


Timer period number 


HoShifts 


Double 


number of planned shifts during the 
time period 




LoadingPactor 


Double 


Planned loading rate (e.g. % 
utilisation) 


15 


YieldPaetor 


Double 


Target yield valuee 




DowntimePactor 


Double 


Projected downtime 




CapacityRequired 


Double 


Capacity required 




CapacityAvailahle 


Double 


Capacity available 


Production Capacity Header 

Reader file defining the Production Resource a Time resolutions a valuee 
for various Production Capacity Data 


25 


Field Identifier 


Field Type 


Description I 




Product CapacityHea 
derZD 


Long 


Production Capacity Header ZD 


30 


ResourceResolution 


Text 


9 for Production Node, RO for 
Production Group and R for Production 
Resource f 




ResourceZO 


Text 


Resource ( Resource , Group or Node) 
associated with en aggregate 
production plan 


35 


CapacityOnit 


Text 


Example, number of production hours, 
shifts, etc. (related to the time 
resolution) 




TlmeResolution 


Text 


D for day; w for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 


40 






annually. 




Calendar ZD 


integer 


Pegged to a predefined calendar 




OateCreated 


Date/Time 


Date when the aggregate production 
plan was created (based on the time 
resolution) 


<5 


ScenarioOata 


Boolean 


Yes if it ie scenario data. No 
otherwise 




ScenarloCounter 


Byte 


Number of scenarios in which this 
header participates 
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Production Matrix 

Aggregate matrix defining the production rates for Product X Resource 
combinations 



5 



10 



20 



Field Identifier 


Pield Type 


Description 


ProductMatrixXD 


Text 


Identifier for the production matrix 


ResourceResolut ion 


Text 


Resource resolution identifier 


Resource ZD 


Text 


unique laentixier sor cne proou cx ion 
resource (e.g., PA1Q) 


ProductResolution 


Text 


Product resolution: C for Component, P 
for Product, a for Product Group 


Product XO 


Text 


Unique identifier for input product 
(groupj^^ 


YieldRate 


Double 


Actual yield rate for the product on 
the resource 


TimeResolution 


Text 


D for day; ff for week; P for bi- 
weekly; N for monthly; B for bi- 1 
monthly; Q for quarterly; and A for | 
annually. 1 


ProcessTime 


Double 


Actual time of production | 


SetupMatrixXD 


Text 


Identifier for the setup time matrix | 


Production Node 

Data for the product i 


on node 




Pield Identifier 


Pield Type 


Description 1 


Product ionNode ID 


Text 


Ohique identifier for the production fj 
node (e.g., PTVNodel) H 


Product lonNodeWams 


Text 


Name of the production node R 


Coinuent 


Text 





35 

Production Requirements Data 

Production Requirements Data for the product identified in the header 





Field Identifier 


Field Type 


Description 1 




40 


ProdReqHeaderlp 


Long 


Production Requirement Header 
identifier (see Production 
Requirements Data Header table) 




TlmePeriod 


Date/Time 


Time period number 




Quantity . ^ 


Double 


Number of units of production 




45 


ProposedChange 


Double 


Proposed change with respect to the 
quantity 
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8 



10 



15 



20 



25 



40 



Production Requir«n«n 
Header file defining 
Product Requirements 


ts Reader 
the Product X 
data 


Tine resolutions 4 values for various 


|| Pield Identifier 


Pield Type 


Description 


ProdReqHeadarlD 


Long 


Production Requirement Header 
Identifier 


APPID 


Text 


Identifier for an aggregate production 
plan 


Productftasolution 


Text 


Product Resolution: P-Prodct , a-Group 1 


pi ji lL.jir TTi 




rrooucc ass ociacco witn tne production n 
requirements plan | 


ti me Resolution 


Text 


■% M * U M m mm - >— « ^ « » U 

D for day; w for week; F for bi- 
weekly; N for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


DateCreated 


Date/Time 


Date when the production requirements 
plan was created (based on the time 
resolution) 


ScenarioData 


Boolean 


Yes if it is scenario data, No 
otherwise 


ScenarioCounter • 


Byte 


number of scenarios in which this 
header participates 


Promotional Data 
Data related to past 
header 


and future pr 


emotions for Products ft Customers in the 


Field Identifier 


Field Type 


Description 1 


Promot ionHeader ID 


Long 


Promotion Reader Identifier fj 


TlmePeriod 


Date/Time 


Timer period number (beginning of the y 
time period) 1 


Promot ionDur at ion 


Double 


Time duration for the promotion | 


Pre - evaluat ionQty 


Text 


Estimate before the promotion tor the 1 
sales qty due to the promotion | 


Post-evaluationQty 


Text 


Estimate after the promotion for the 1 
sales qty due to the promotion 1 



45 
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Promotion Reader 

Header file defining the Product X customer X Tine resolutions a values for 
various Promotion data 



* 


Field Identifier 


Field Type 


Description 




PromotlonBeaderXD 


Long 


Identifier for the Promotion Header 


10 


CufltoatarRa solution 


Text 


Customer Resolution t 8 for Customer 
Ship to, c for Customer, 0 for Customer 
Group, A for all 




Customer ID 


Long 


Should be a valid customer group or a 
null set (e.g.. Selling floor) 




ProductAesolution 


Text 


Product Resolution: P for Product, G 
for Product Group, A for all 


15 


ProductXD 


Text 


Product associated with the promotion 
Data 


20 


TimeResolution 


Text 


D for day; « for week; F for bi- 
weekly; M for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. 




Calendar ID 


Text 


Pegged to a specific calendar 




Promot ionType 


Text 


R for Retailer; P for PCBC; C for 
Competitor 


25 


Promo t ionClass 


Text 


Promotion class (e.g. Price 
Reductions) 




Promot ionlnt ens i ty 


Double 


Intensity of the promotion (low, 
medium, high) 


30 


Promot lonShape ID 


Umq 







DateCreated 


Date/Time 


Date of creation of the Promotion \ 
Header 




ScenarioData 


Boolean 




35 


ScenarioCounter 


Byte 






Resource 

Data related to production resource 












Fluid Identifier 


Field Type 


Description 


40 


Resource ID 


Text 


Ohique identifier for a production 
resource (e.g., FA1G) 




ResourceName 


Text 


Descriptive name 




" ResourceGroupID 






45 


Text 


Production group this resource belongs 
to 




MaxLineRate 


Double 


Maximum line rate 




HoWorkatations 


Double 


Number of workstations 


50 


MaxBuffers 


Double 


Maximum number of buffers \ 
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Resource Oroup 



to 



1$ 



Field Identifier 


Field Type 


Description 


RaaourceGroup ZO 


Text 


Unique identifier for the production 
group (e.g., Plant*) 


ReeourceOrouoHane 


Text 


Descriptive name 


Product ionNode ID 


Text 


Production node this group belongs to 


Attributel 


Text 


Attribute (e.g.. Category, Location) 


Attributes 


Text 


Attribute (e.g.. Category. Location) 


Attributes 


Text 


Attribute (e.g.. Category. Location) B 


ScenarioQroup 


Boolean 


Yes if this is scenario group; Uo B 
otherwise 1 



Resource Group definition 



25 



Field Identifier 


Field Type 


Description 


ResourceOroupParentZO 


Text 


Identifier for the resource group 
that is the parent 


ResourceOroupChildXD 


Text 


Identifier for the resource group 
or product that is the child 



Sales Requirements Data 



Field Identifier 


Field Type 


Description 


SalesReqHeadorXD 


Long 


Header ID pegged to the Sales 
Requirement Header table 


TimePeriod 


Date/Time 


Time Period pegged to the time 
resolution in the Sales requirements 
header table 


Quantity 


Double 


ftiaAtlty^remiired 



<5 
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Sales Requirements Be 
Reader file defining 
requirements data 


ader 

the Product X 


Time resolutions' a values for the sales 


H Field Identifier 


Field Type 




SalesReqHeaderlD 


Lca ? 


Header ID of the sales requirement* 


ProductResolution 


Text 


Production Resolution: P- Product, 
P0- Product Group, A- All 


ProduetZD 


Text 


Product ID 




Text 


— — { 

Tine Resolution: D-Day, if -Weekly, M- 
Honthly. 0-Ouarterly, Y-Yearly 


Calendar ZD 


Long 


Calendar ID 


DeteCreated 


Date/Time 


Date of creation of the sales 
requirements 


ScenaxioData 


Boolean 


Yes if it is scenario data. Ho 
otherwise 


SeenarieCounter 


Byte 


. * , w< w ^ fl 
Number of scenarios in which this n 

header participates H 


Scenario 

woiurio acscripcioo 


m mm I • M mm mm 4 mm S mm 

ana user xnxo 


rmatioa 


Field Identifier 


Field Type 


Description 1 


ScenarioIO 


Loner 




ScenarioName 


Text 




User 


Text 




Description 






DateCreated 


Date/Time 




DateUpdated 


Date/Time 





Scenario Data Compatibility 

Table that specifies what data headers can be loaded into each of the data 
wcketa on each form for eech frame 



Field-Identifier - 



Frame 



Form 



Pocket 



TableName 



Field Type 



Text 



Integer 



Integer 



Text 



Description 



Frame Name 



Form Number 



Pocket Number 



Table name for the (Frame, Form, 
Pocket) triple 
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Scenario Definition 

The cable that contain* the header ids of the various data that exists in 
each pocket, in each form In each frame for different scenarios 



Field Identifier 


Field Type \ 


Description T 


ScenarioXD 


Lony 




Frame 


Text 




Form 


Integer 




Pocket 


Integer 




Reader ID 


Long 




DateCreated 


Date/Time 




DateUpdated 


Date/Time 




Setup Matrix 
Aggregate matrix def i 
chanjeovers^ 


aing the sequ 


ence* dependent setup times* for product 


Field Identifier 


Field Type 


Description 


SetupMatrixXD 


Text 


Identifier for the Setup Matrix 


Prev Product ID 


Text 


Identifier of the product that has 
just finished processing 


NextProductID 


Text 


Identifier of the product to be set-up 
on the resource 


Tlmeftesolution 


Text 


D for day; w for week; F for bi- 
weekly; H for monthly; 8 for bi- 
monthly; Q for quarterly; and A for y 
annually. | 


SetupTime 


Double 


Actual time to ^et^io J 


Supply Chain Network 

sLruCbuIBl (Uba Bpoci 


f\Hno thn nun 


nlv chain nAfwnrlr 


Field Identifier 


Field Type 


Description H 


Link ID 


Text 


Supply chain network link identifier 


FromHodeXD 


Text 


A node ID from any of the three node 
classes: component supply , production 
inventory 


ToNodelD 


Text 


A node ID from any of the three node 
classes: production, inventory, demand 


LinkCapacity 


Double 


Capacity of the link 


Transport LeadTime 


Double 


Transport Lead time associated with 
the link 


Distance - - 


Double 


Transport at ion distance 


Link Indicator 


Boolean 


Yes if it is currently active and in 
use and No otherwise 
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Supply Order Data 
Data^o^hajiujDlv^r^^ 



5 


Pield Identifier 


Pield Type 


Description | 




SupplyOrderHeaderlD 


long 


Production or supply order (e.g. pcee B 
type 4 orders) y 


10 


orderOate 


Date/Time 


Date of creation expressed with 
respect to calendar 




OrientationDatalD 


Text 


Orientation order associated with 
supply order 




OueOate 


Date/Time 


Date the supply order is due 


15 


OuAntitv 


Double 






Supply Order Eeader 
Seeder file defining t 
supply orders 


he Product X 


Customer X Time resolutions a values for 


20 


Field Identifier 


Pield Type 


Description 




SupplyOrderBeaderlO 


Long 


Production or. supply order (e.g. pcee 
type 4 orders) 




Cue tome r Iteaolut ion 


Text 


S for customer ship to; C for 
customer; Q for customer group; M for 
market; A for all customers 




Customer ID 


Text 


Customer identified with the place 
keeping order 


30 


Product Reeolut ion 


Text 


P for product; 0 for product- group; A 
for all products 




Product ID 


Text 


Product associated with the supply 
order 


38 


TimeRe solution 


Text 


D for day; W for week; P for bi- 
weekly; m for monthly; B for bi- 
monthly; Q for quarterly; and A for 
annually. | 




Calendar ID 


Long 


Pegged to a calendar 




DateCreated 


Date/Time 


Date the Supply Order Header was 
-created/modified 


40 


ScenarioData 


Boolean 


Yes if it is scenario data. Mo 
otherwise 11 




ScenarioCounter 


Byte 


Number of scenarios in which this | 
header participates | 



Temporary Product List 

System table that contains a temporary product list 



Pield Identifier 


Pield Type 




Product ID 


Text 


Description | 



55 
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VMR Contract 

DatajssocJlate^jit^aVen^ 



5 

10 
IS 
20 

30 
35 


Plaid Identifier 


Pield Type 


Description 




VMRContraetXD 


Text 


Identifier for the VMS Contract 


ContractData 


Date/Time 


Data of the contract 


BxptrationData 


Date/Time 


Expiration data of the contract 


Payment Terms 


Text 


Example: Net-60. Net- 30 


Product Resolution 


Text 


Product Resolution: P for Product. 0 
for Product Group, A for all 


Product ZD 


Text 


Product associated with the VKR 
contract 


TargetPillRate 


Double 


Pill rata promised in the VKR 
contract 


TurnAroundTlme 


Double 


Momiaml turnaround time 


iUnZnvantoryPaetor 


Double 


Minimum inventory factor agreed in 
the vmr contract 


MaxInvantoryPactor 


Double 


Maximum inventory factor agreed in 
the VMR contract 


OrderRevieionPactor 


Double 


Customer's righta to reviae order 


VKR Data 

Data associated with Vendor Manage* 
Identified in the header 


1 Replenishment for the customers 


Pield Identifier 


Pield Type 


Description 


VMRKeaderXD 


Long 


VMR Reader Identifier 


Order Date 


Date/Tine 


Date when the VMR order data was 
entered 


PurchaseOrder ZD 


Text 


Customer purchase order reference 


Orders tatua 


Text 


A Cor allocated/ B for backordered; 


OrderOty 


Double 


Quantity associated with the order 


CumDel 1 veryQty 


Double 


Quantity delivered against the order 
(cumulative measure) 


DueDate 


Date/Tine 


Date when the order is planned to be 
delivered at the customer site 


40 


DellveredDate 


Date/Time 


Date when the order waa actually 
received at the customer site 




ShipOate 


Date/Time 


Date when the order la planned to be 
shipped 




Las t Shipment Da te 


Date/Tim 


Data of the latest shipment - made to 




45 

50 
55 






tulfill an order 




ShipCarrier 


Date/Time 


The carrier used in delivering the 
order (to keep track of the in trans it 
inventory) 




LinkID - . . - 


Text ... 


Pegged to a defined supply, chain link 
in the supply chain network table 




Pre ightRateTabl e ID 


Text 


Based on transportation mode 
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vmr Header 

Header file defining the Product X Customer X Time resolution* a vales for 

VMR ; 



5 



10 



15 



20 



30 



Field Identifier 


Field Type 


Description 


VMHHeaderXD 


Long 


VMR Header Identifier 


CustomerResolutioa 


Text 


Customer Resolution: S for Customer 
Shlpto; C for Customer; 0 for Customer 
Group. A for all 


II VUSMWHAm 


Text 


Should be a valid cuetomr orouo or m. 
null set (e.g.. Selling floor) 


ProductResolution 


Text 


Product Resolution: P for Product, a 
for Product Group. A for all 


Product ID j 


Text 


Product covered by the VMR contract 




Text 


weekly; N for monthly; B for bi- 
monthly; 0 for quarterly; and A for 
annually. 


Calendar ID 


Integer 


Pegged to a predefined calendar 


Inventor/Control ZD 


Text 


Pegged to inventory control parameters 
ZD 


| VMRConcr actio 


Text 


Pegged to the VMR Contract table 


J OateCreated 


Date/Time 


-Date the VMR Header was 
created/modified 


i ScenarioData 


Boolean 


Yes if it is scenario data. Mo 
otherwise 


9 ScenarioCounter 


Byte 


Number of scenarios in which this 
header participate© | 



35 



40 



45 



SO 
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Appendix B 

Database Specifications for Equipment Repair Supply Chain 
5 The following are the specif i cat ion* of the data cables for the equipment 

repair supply chain. 



Equipment 

Information to classify equipment into groups. Thin information is 
relevant to Identify reliability characteristics of equipment parte. 



15 



Field Identifier 


Field Description 


Equipment ZD 


tznique identifier for the equipment 


Equipment Location 


Location of the equipment 


Inspect ionLocat ion 


Location where the equipment is 
inraacted/maintnlned 






RunalngHoure 


Total Cumulative running hours so far 


Region 


Region of reconnaissance associated with the 
equipment 


Characteristic 
< Identify) 


Other critical characteristic, e.g., total running 
time 


etc. 




Repairable Item end 
Component 


Component Information 


Pleld Identifier 


Field Description 


Component ID 


Component ID in the BOM 


ComponentKame 


Berne of the component 


MinPeckQuantity 


Minimum pack quantity 


Phys i ca 1 Paramet er 


Physical dimensions for the component 


CompCategory 


a for Off-the-shelf; C for Customized 


Packaging Instruct 
ion 


Special packaging requirements 1 



40 Engineering Bill of Material that describes the product structure from 

equipment to repair items to components. 



45 — 


Field Identifier 


Field Description 


BOM ID 


Unique identifier for the engineering BON 


ParentType 


Type of the parent r Equipment /Repair- Item/ Component 


50 


Parent ID 


Identifier of the parent (Equipment ID or Repair I temlD 

or Component ID) 1 


ChildType 


Type of the child (Repair Item/component) 


ChildiD 


Unique identifier for the child (RepairltemID or 
Component ID) 


Quantity 


Number of components used in parent 



55 
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10 



Repairable Item 



Field Identifier 


Field Description 


RepairltemXD 


Unique identifier of the repair item 


Repairltemtfame 


Kama/Description of the repair item 


FhyeicalDlmensions 


Height X Depth X Width 


weight 


Weight of the SOT 



Component Supplier 



15 



20 



Field Identifier 


Field Description Hj 


CompSupplierXD 


unique Identifier for the component supplier 


SuppllerName 


Kame of the component supplier 


FaymentTerme 


Example: Net««0 


StreetAddrees 


Street Address 


StateZO 


Name of the State 


FostalCode 


Foetal code 




Heme of the country 



30 



Supply Information 
Repair Time Matrix 

Aggregate matrix defining the repair rates for Repair Item X Repair 
Resource combinations 





| Field Identifier 


Field Description 




35 


RepairMatrixID 


Identifier for the repair matrix 


ResourceResolution 


Resource resolution identifier 


ResourcelD 


unique identifier for the repair resource 


RapairltemID 


unique identifier for the repair item 


TiroeResolution 




40 




D-for day; W for week; P for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 




ProcesaTime 


Mean time to repair 


SetupMatrixIO 


Identifier for the setup time matrix 
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Repair Setup Matrix 

Aggregate matrix def ining the sequence dependent setup tinea for repair 
item changeovora ' 



FXeia iQenmxer 




SetupKatrixID 


Identifier for the Setup Katrix 


PrevProduetZD 


Identifier of the repair item that has just bees . 
repaired 


NextProductlD 


Identifier of the repair item that needa to be 
repaired 


TimeResolutian 


D for day; w for week; P for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. 


SetupTime 


Actual time to setup 



Repair Capacity Header 

Header file defining the Repair Resource X Time resolutions a values for 



various Repair Capacity 


f Data 


I Field Identifier 


Field Description fj 


RepairCapacityReader 


Repair Capacity Reader IS 


ResourceResolutlon 


Resource Group or Resource 


ReeourceXD 


Resource ID 


CapacityUnit 


Example, number of production hours, shifts, 
etc. (related to the time resolution) 


TimeResolution 


D for day; w for week; P for bi-weekly; N for 
monthly; B for bi-monthly; Q for quarterly; and U 
A for annually. J 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date when the aggregate repair plan was created 
(baaed on. the time resolution) 



Repair Capacity Data 

Repair Capacity Data of the repair resource Identified in the header 





Field Identifier 


Field Description 




-RepalrCapacityOata- 


Repair Capacity Data- ID . 


40 

45 


ID 






TimePeriod 


Time period number 


RepalrCapacltyHead 
erID 


Repair Capacity Header ID (See Repair Capacity 
Header Table) 


KbShifta "~ 


-Nuaber-of-plaimed-shifta-durii^the-ti 


50 


LoadingPactor 


Planned loading rate (e.g. % utilixatian) 




Downt imePac tor 


Projected downtime 




CapacityRequlred 


Capacity required 




CapacityAvailable 


Capacity available 
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Repair Estimation Header 

Header file defining the Item X Time resolution* ft values for various 
Repair estimation data 



Field Identifier 


Field Description 


RepairBstHeaderXX) 


Repair Estimation Header Identifier 


ARPZD 


Identifier for an aggregate repair plan 


ZtemZD 


Item associated with the production requirements 
JE122L 


TimeResolution 


D for day; tr for week; F for bi-weekly; M for 
monthly; B for bi-monthly; 0 for quarterly; and A 
for annually. 


Calendar ZD 


Pegged to a predefined calendar 


OateCreated 


Date when the Repair Estimation plan was created 
(based on the time resolution) 


Repair Be timet ion Data 

Repair Estimation Data for the repair item identified in the header 


Pield Identifier 


Field Description 


RepalrBstDatalD 


Repair Estimation Data ID 


TimePeriod 


Time period number 


RepairSatHeaderlD 


Repair Estimation Header Identifier 


Quantity 


Number of unite of production 1, 


ProposedChange 


Proposed change with respect to the quantity 



Aggregate Repair Plan Header 

header file defining the Repair Item X Resource X Time resolutions 4 values 
for various Aggregate Repair Plans 



| Field Identifier 


Field Description 


RepairPlanHeaderlD 


Repair Plan Data Series Identifier 


RepeirlD 


Identifier for an aggregate repeir plan 


ResourceResolut ion 


Resource Resolution: R-Reaource, G- Group, N-Node 


ResourcelD 


Resource associated with the repair plan 


RepairltemResolution 


Repair Item Resolution: P- Repair Item, O- Group 


1 Repair I temlD 


Repair Item associated with the repair plan 


1 TimeResolution' 


D for day: tr for week; F for bi-weekly; N for 




monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


1 Calendar ID 


Pegged to a predefined calendar J 


| OateCreated 


Date when the aggregate production plan was 
created (based on the time resolution) 
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Aggregate Repair Plan Data 

Data related to the aggregate repair plan for the repair item identified in 
the APP header 



Field Identifier 


Field Description 


RepairPlanDataXD 


Identifier for the Repair Plan Data 


TimePeriod 


Tine period number 


RepalrPlanHaadax 

ID J 


Repair Plan Read identifier (see aggregate repair 
.plan Reader table) 


Quantity 


Number of unita to be repaired 


PropoaedChange 


Recommended change in the planned quantity (to store 
changes between regeneration of Repair Plans) 


Header file definix 
requirement data 


o Reader 

tg the Component X Time values for various component 


W+A - * w ■ AMI — — 

Field Identifier 


Hi -1 J mm.—. * - -» - - 

Field Description 


OompKfff KftaderlP 


component Estimation Header Identifier 




Component aaaociated with an component estimation 
header 


BOKZD 


Unique identifier for ROM 


DateCreated 


Date when the component estimation was created (based 
en the time resolution) 


TimeResolution 


D for day; if for week; F for bi-weekly; H for 
monthly; R for bi-monthly; Q for quarterly; and A for 
annually. 


Calendar ZD 


Pegged to a predefined calendar 


RepairPlanID 


Pegged to an aggregate repair plan (if warranted) 



Component Estimation Data 
Data related to requirements for the o 



Field Identifier 



CompRstDatalD 



TimePeriod 



ComReqHe aderlD 



Quantity 



^ropoaedChangc 



identified in the header 



Field Description 



Component Estimation Reader ID (See Component 
Estimation Header Table) 



Time period number 



Identifier for the component estimation header 



number of unita during the time period 



Proposed- Change- in required quant ity 



50 
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Material Delivery Schedule Header 
Header file defining the 



it X Supplier X Time resolution* a values 



1 Field Identifier 


Field Description 


MDSHeaderXO 


Identifier for the Material Delivery Schedule f 
Header I 


Component Supp lytf ode 


Identifier for component supply node 


SupplierXO 


Supplier asaociated with a Material Delivery 
Schedule 


TimeReaolution 


D for day; it for week; F for bl -weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 


CalendarXO 


Pegged Co a predefined calendar 


| DateCreated 


Date when a Material Delivery Schedule was created 
(based on consistent time units) 



Material Delivery Schedule Data 



Field Identifier 


Field Description 


MDSDataZD 


Identifier for Material Delivery Schedule Data 


DeliveryDate 


Material Delivery Date 


MDSHeaderlD 


Identifier for the Material Delivery Schedule Header 


Quantity 


Number of units of material delivery 



Requirements Information 
Requirements History Header 

Header file defining Equipment X Repair Item X Time resolutions a values 
for various demand histories 



I Field Identifier 



ReqHistHeaderlD 



RepairltemResolution 



RepairltemID 



BquipmentResolution 



Equipment ID 



TimeReaolution 



Calendar ID 



Field Description 



Identifier for a requirements history header 



p for. repair. item;_G_ f or_repair_i tern Group ;_ A^f or _ 
all repair items 



Repair Item associated with requirements history 



C for Equipment; CO for equipment group; 
all equipment 



A for 



Squipment~(6roup)~associated-with-reqttirementa 
history 



D for day; w for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A 
for annually. 



Pegged to a predefined calendar 
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Requirement* History Data 



5 


Field identifier 


Field Description 




ReqHistDatalD 


Requirement! History Data identifier (see 
Requirements History Header table) 




TimePeriod 


Time period number 


10 


ReqHl a tfleader ZD 


Identifier for a requirements historv header 




RequlrementsQty 


Requirements Quantity^ 


13 


equipment Repair Oa 
Data for actual eqi 


rders 

ilpment repair orders 




Field Identifier 


Field Description 




RepalrOrderlD 


ZD for the actual equipment repair order 


20 


Line x w Bsuy 


wini xcem wxcnxn cne oroer 




RepairOrderRefHo 


Repair order identifier 




Equipment ID 


Bquipment identified with the order 




Repair I temID 


Repair Item associated with the order 


23 


Calendar ID 


Pegged to a calendar 




TlmeResolution 


D for day; w for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and A for 
annually. | 


30 


OrderEntryDate 


Expressed in terms of the calendar and time 1 
resolution 




RequestedDate 


Bxpressed in terms of the calendar and time 
resolution 


35 


DueDate 


Bxpressed in terms of the calendar and time 
resolution 




ShipOate 


Expressed in terms of the calendar and time 

resolution | 




Deliver/Date 


Bxpressed in terms of the calendar and time 1 
resolution |j 


40 


Quantity 


Quantity of the order | 




Comments 


Such as value added services associated with the U 
order 1 



50 
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Future Requirements Reader 

Header file defining the Cuetomer X Product X Time resolution* 6 values for 
various future requirements 



5 



25 



Field Identifier 


Field Description 


FutureReqHeaderXD 


Future Requirements Keener xaentxiier 


RepairltemResolutiaa 


P for Repair Item. 0 for Repair Item Group, A 
for all Repair Items 


RepairltemZD 


Repair Item (Group) associated with, forecast 


BquipmentResolution 


C for Equipment, CG for equipment group; A for 
all equipment 


Equipment ID 


Equipment (Group) associated with requirements 
history 


TimeResolut ion 


D for day; W for week; F for bi-weekly; M for 
monthly; B for bi-monthly; Q for quarterly; and 
A for annually. 


Calendar ID 


Pegged to a predefined calendar 


DateCreated 


Date when the forecast was created (based on the 
time resolution) 


FutReqType 


B for bottom-up; T for top-down 


BstimationAssumptions 


Assumptions associated with the estimation 


BstimateOvner 


Author of the future requirements 



Future Requirements Data 

Data associated with the future requirements for the equipment -repair items 
identified in the header 



35 



|| Field Identifier 


Field Description 


FUtureReqDataXD 


Future requirements data series identifier 


TlmePeriod 


Time period number 


FutureReqHeaderXD 


Pegged to the Future Requirements Header Table 


Estimate Value 


Future requirements data value 


SstimateCV 


Coefficient of vsrietion of estimate 



40 
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Activity Header 

Header file defining the Equipment Group X Repair Item X Time resolution* a 
values for various Activity data 



Field Identifier 


Field °^£iBsb\£« 


ActivityfleaderXD 


Identifier for the Activity Header 


| BquipmentResolution 


Equipment Group Resolution: C for Equipment, 0 

for Equipment Group, A for all \ 


Equipment ID 


ID of the equipment associated with the. activity 


| RepairltemResolutlon 


Repair Item Resolution: P for Repair Item, 0 for 
Repair Item Group, A for all J 


I RepairXtemZO 


Repair Item associated with the activity Data 


TimeResolut ion 


0 for day; W for week; 9 for bi -weekly; M for fl 
monthly; B for bi-monthly; Q for quarterly; and A tj 
for annually. 1 


Calendar ID 


Pegged to a specific calendar | 


ActivitvType 


Company wide, location level, etc. 


ActivityClaee 


Activity class 


Act ivltylntanaity 


Intensity of ths activity (low, medium, high) 


ActivityShapeXD 


Intensity of the activity (low, medium, high) 1 



Activity Data 

Data related to past and future activities for the equipment 



Field Identifier 


Field Description 


ActlvityDataXD 


Activity Data Series Identifier 


TlmePeriod 


Timer period number (beginning of the time period) 


Act i vi tyHeader ID 


Activity Header Identifier 


ActivltyDuration 


Time duration for the activity 


Pre- 

evaluationQty 


Estimate before the activity for the quantity due to 
the activity 


Post* 

evaluationQty 


Estimate after the activity for the quantity due to 
the activity^ 







50 
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Inventory Information 
Inventory Bender 
Bender file defining the Repair Item X Time resoluti 
date 



a valuee for 



Field Identifier 


Pield Description . wmm „. 








Tiianf 4 *• A v for mi < wwiiMifv looie warehouse 




Identifier for inventory control parameters 


ItemResolution 

9 


Item Resolution: C for Component, P for Product , 0 
for Product Group and A for All 


I RepairltemXD 


Repair Item id — -bi _ 


TimeReeolution 


D for day; w for week; 7 for bi-weekly; K for 
mmrhiv: B for bi- monthly; Q for Quarterly; and A 
for annually. 


Calendar ID 


Pegged to a predefined calendar 


Minlnventory Level 


Minimum inventory level for the item 


Maxlnvent oryLe ve 1 


Maximum inventory level for the item 


Inventory Data 
Tnvuntorv data for il 


:ema identified in the header 


jr aa 

Pield Identifier 


Pield Description 


InventoryDatalD 


Inventory data identifier (see Inventory Header 
table) 




Time period number 




Inventory Data Series Identifier 




On-hand available inventory for allocation J 




On -order inventory 




Back-ordered inventory 




In- transit quantity 


Reeervedlnventory 


Reserved inventory on -hand but available for 
- allocation-only in caae of emergency 



45 
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Inventory parameters 



Fl«ld identifier 


Field Description 


Invent oryCont rol ID 


Identifier for inventory control parameters : Assume 
inventory planning- inventory control 


SafetvStocxFactor 


Safety stock, factor 


TargetServiceLevel 


Target service level 


PolicvType 


Policy type: S3. Min/Kax, QR, etc. 


Wan i pvWbPtyygfcP* 


KH h 4 ww ww inv«At an/ faetar tm a in t«mi o£ mmIu H 

of sales) n 


MaxinventoryFactor 


Maximum inventory factor (e.g., in terms of weeks 
of sales) 


MinOrderQtyFactor 


Minimum order quantity factor 


CarrvChargeFactor 


Carrying cost factor 


OrderChergeFactor 


Ordering cost factor 


InventoryClass 


Inventory classification J 


ReplenishmentFrequ 
1 ency 


Frequency of replenishment w.r.t. the time | 
resolution in the header w 



Repair Resource Information 

Information related to the repair technician and test equipment 
Repair Resource 



Field Identifier 


Field Description 


RepairResID 


Unique identifier for a repair resource (e.g., FAlG) 


RepairResKams 


Descriptive name 


Repai rResOrouplD 


Repair resource group this resource belongs to 


MaxLineftate 


Maximum line rate 


NoWorkstationa 


Number of workstations 1 



Repair Resource Oroup^ 



Field Identifier 


Field Description 


RepairResOroupXD 


Unique identifier for the repair resource group 
(e.g., Plant 4) 


Repai rResOroupKams 


Descriptive name _ J 


Repai rKodelD 


Repair node this group belongs to 


Attributel 


Attribute (e.g., Category, Location) H 


| Attribute* 


Attribute (e.g., Category, Location) 


8 Attribute! 


Attribute (e.g., Categorv^^^JiiSSl™ 
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Appendix C 

Interim Design Documentation for the System Integrator 
of the Supply Frame Chain Manager 

Class name: 

PrameManager 

Category: Supply Frame Chain Manager 
Documentation : 

This is a singleton class. It is running on the server. 
It has to be started before a client can start and make 
connection to it. The PrameManager is responsible to 
facilitate the integration of the client side of the 
system (the User Interface 18) with the server side of 
the system where the mathematical Model Engines and the 
DSS 10 database reside. The PrameManager is composed of 
a ClientManager, a ServerManager, a collection of 
Requestlnterpreter and objects which form the Functional 
Integrator 312. When a client program start up, it will 
connect to the PrameManager (obtain the object reference 
of the PrameManager) and call the initialization 
function. As part of the initialization of the client 
with the PrameManager, a Requestlnterpreter object will 
be created, inserted into the collection and the object 
reference will be return back to the client. The client 
will also be registered with the ClientManager object of 
the PrameManager. The initialization also includes the 
user authentication. 
Export Control: Public 
Cardinality :l 
Hierarchy: 
Superclasses : none 
Associations: 

<no rolename> : ClientManager in association 
<no rolename> : Requestlnterpreter in 

association 

<no rolename> : ServerManager in association 
Public Interface: 
Operations: 

PrameManager 
initializeClient 

Private Interface: 
Attributes: 

mClient Manager : ClientManager 
mServerManager : ServerManager 

mRequ est Interpreter—: ■- 

List<RequeatInterpreter> 

A linked list of 
Requestlnterpreter. Each Requestlnterpreter will run in a 
separate thread or a separate process. This way, requests from 
multiple clients can be handled concurrently. 

St ates -ma chine : No 

Concurrency : Sequential 
Persistence : Transient 
Operation name: 
FrameManager 
Public member of : FrameManager 
Arguments: - 

char*frameMgrConf igFile 
Document at ion : 

This is the constructor is the FrameManager. At the 
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construction time, it will read in the configuration 
information from a file ("frameMgrConfigFile") . The 
information include things such as the name of the DSS 
Database and on which host it is running, where are the Model 
Engines (installed on which machines), how many number of 
simultaneous client are allowed to connect to the 
FrameManager, etc. The constructor is also responsible to 
initialize all other data member of this class. 

Concurrency * Sequential 

Operation name: 

initialized ient 

Public member of : FrameManager 

Return Class: Request Interpreter* 

Arguments : 

ehar+userName 

char+hostName 

char+password 

ffotifyMsg&notifyMsg 
Documentation: . 
Once the client program has started and obtained the 
object reference of the FrameManager, it will call this 
function to initial itself with the FrameManager. It will 
pass in, the user name, password, host name, etc. The 
information will be used for authentication and registering 
with the ClientManager. The object reference of a NdtifyMsg on 
the client side will pass in. This object reference will be 
used to notify the client about its request when it make an 
asynchronous request. (Asynchronous request will be allowed 
when the client request to run some of the strategic decision 

model . ) - 

This function will return the object reference or a 
Request Interpreter through which the client will make all its 
requests . 

Concurrency : Sequential 
Class name: 

ClientManager 
Category: Supply Frame Chain Manager 
Documentation: 

Manage and monitor the client connection. Implement 
client connection policy, such as "after certain period of 
inactive time disconnect the client", "the total number of 
client connection can not exceed certain number". Also 
resposible to delete the corresponding Request Interpreter 
object after a client is disconnected (in such case as the 
client machine goes down, or the network connection is lost) . 
Export control : Pubrirc 



Cardinality:! 
Hierarchy: 
Superclasses : none 
Associations: 

<ho rolename> : FrameManager in association 

public- Interface: 

Operations : 

registerClient 
naitainClient 

Private Interface: 
Attributes: 

clients : List<Client> 

A linked list of Client. The 
Client class contain the basic information about the* client, 
such as, the user name, the client host name, the 
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corresponding Request Interpreter, time of initial connection, 
tine of last request , pending requests, etc. 

State machine: No 

Concurrency : Sequent ial 

Persistence : Transient 

Operation name: 

registerClient 

Public member of :ClientManager 

Return Class: boo 1 

Arguments: 

Client&adient 
Documentation: 

Add a client to the client list. Enforce the relevant 
PrameManager policy such as the maximum number of simultaneous 
client . 

Concurrency : Sequential 
Operation name: 

maitainCllent 
Public member of : CI lent Manager 
Documentation: 

This function will be called periodically from the 
PrameManager. within the function, each client will be 
checked to see if it needs to be disconnected* If a client 
needs to be disconnected, it will be removed from the list and 
the corresponding Request Interpreter object will be deleted. 
Concurrency : Sequential 
Class name: 

Requestlnterpreter 
Category: Supply Frame Chain Manager 
Documentation : 

This is the object the client is normally interact 
with. Each object of this type has to run in its own thread or 
process so that multiple client can request server services 
concurrently. 

Export Control :Public 
Cardinality :n 
Hierarchy : 

Superclasses : none 
Associations : 

<no rolenamo : PrameManager in association 
Public Interface: 
Operations: 

request 

Private Interface: 
Attributes: 

theClient— : - Client * — 

Reference to the client with whom this 
Interpreter is associated. 

State machine :Ko 

Concurrency : Sequential 

Persistence : Transient 

Opera t ion na me: . 

request 

Public member of : Request Interpreter 
Return Class :bool 
Arguments : 

longscenarioID 

longdomalnID 

longrequestID 

boolasynch 

long&resultID 
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Document at ion : 

This function will be called by the client to make a 
request to perform certain task by the server (s). The 
scenarioIO and domainIO will identify the data associated with 
the request. The request ID will identify what kind of action 
need to be performed (by looking up a table within the 
system). If the request is not asynchronous ("asynch* false") 
the result will be returned immediately through the value of 
reeultlD. The client can retrieve the actual data from the 
DSS Database through the resultID in the table associated with 
that type of request. If the request of aynchronoua, the 

result will be sent to the client later by calling the 
NotifyMsg object of the client. 

Concurrency ; Sequential 

Class name: 

Server-Manager 

Category: Supply Frame Chain Manager 

Documentation : 

Manage the server connection. A server is a program 
(an object) from which we can request specific service. Por ' 
exa mp le, we may have a server being able to compute the 
optimal delivery frequency given the maximum inventory and 
service level constrain in a VMR setting. This is referred as 
Model Engine Server. A Model Engine Server can run on the 
same machine where the PrameManager is running, or it can run 
on different machine. Two Model Engine Servers of the same 
type can run on the same machine, or they can run on different 
machines. The information governing the policy is stored in 
the PrameManager configuration file which was read in at the 
time of constructing the FrameManager. The ServerManager will 
enforce the policy such as on which machine to start which 
server, load balancing, etc. The ServerManager is also 
responsible to shutdown the servers when they are not needed. 

Export Control: Public 

Cardinality:! 

Hierarchy: 

Superclasses : none 

Associations: 

<no rolename> : PrameManager in association 

Public Interface: 

Operations : 

addServer 

maintainServer 

getServer 

Private Interface: 

Attributes: 

servers : List<Server> 

A linked list of Server 
object. A Server is a class which record the basic information 
about a server, such as name., type, which host it is running 
on, status, etc. 

State-machine: No 

Concurrency : Sequent ial 
Persistence : Transient 
Operation name: 
addServer 
Public member of : ServerManager 
Return Class: boo 1 
Arguments : 

char+aServer 
Documentation: 
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Try to -start a new server of certain type and add it 
to the server list. Here some of the server management policy 
will be enforced. For example, we may have a policy says that 
there should be no more than x number of Linear Programming 
servers in the entire system. Or we may have another policy 
says that we can not put more than x number of servers (of all 
types) on machine A. When the function is called only the name 
(type) of the server is passed in. Which machine the server ■ 
should be on is determined within this function. 

Concurrency : Sequential 

Operation name: 

maintainServer 

Public member of : ServerManager 

Documentation: 

This function is periodically called from 
FrameManager. It will check each server to see if any one 
needs to be shutdown. 

Concurrency : Sequential 

Operation name: 
getServer 

Public member of : ServerManager 

Return Class : Server* 

Arguments : 

char*aServer 
Documentation : 

Return a server of the specified type. It first 
check the server list to see if any one of that type is idle. 
If it is, it return the reference to that one and update the 
status. If not, it will call the addServer function to try to 
add one. 

Concurrency: Sequential 



Claims 

1 . A decision support system, comprising: 



dedsion support frames providing a view into a supply chain; 

a model engine comprising modeling processes analyzing the chain; and 

a frame manager managing the execution of the modeling processes to provide information for said frames. 

t 2.- A system as recited in claim 1 . further comprising a database management s ystem s upplying database information 

to the modeling processes and said frame manager. 

3. A system as recited in daim 1, wherein said system comprises a server mode including said engine and said man- 
ager and a client mode comprising said frames. 

> 

4. A system as recited in claim 1 , wherein said database comprises an inventory data space, a supply data space and 
a demand data space 

5. A system as recited in claim 2, wherein said database includes a supply chain network including a component sup- 
\ ply node, a production node, an inventory node and a demand node. 

6. A system as recited in daim 1 . wherein said modeling processes comprise a component procurement policy devel- 
opment module, a finished goods distribution network design module, an aggregate production planning module, a 
finished goods inventory management module, a sales forecasting and planning module, a market data analysis 
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module and a vendor managed replenishment module. 
7. A system as recited in claim 1, wherein said manager comprises a system integrator and afunctional integrator. 
5 & A system as recited in claim 1, wherein the supply chain indudes sales, inventory and production. 

9. A decision support system, comprising: 

decision support frames integrating analytical models of a supply chain responsive to a view point of a bust- 
io ness process. 

10. A system as recited in claim 9. wherein said frames comprise a supply management frame, a demand manage- 
ment frame, a vendor managed replenishment frame, a planning, sales and inventory frame and a cfistrfcution net- 
work frama 

13 

11. A system as recited in daim 10. further comprising a domain management process limiting data available to said 
frames responsive to a user selection. 

12. A system as recited in claim 9. further comprising a scenario management process providing scenarios for com- 
20 parison of management plans. 

IX A decision support system, corrprising: 

a demand and supply reconciliation process reconciling production, sales and inventory. 

25 

14w A system as recited in daim 13. wherein said process determines a feasibility capacity plan responsive to supply 
constraints. 

15. A system as recited in claim 13, wherein said process provides a vendor replenishment plan responsive to pre- 
so dieted sales and supply constraints. 

16. A system as recited in claim 1 5. wherein the plan considers production capacity, inventory and point-of-sale infor- 
mation. 

33 1 7. A system as recited in daim 1 5. wherein the plan provides a strategic analysis using quantative model* 

18. A system as recited in claim 13, wherein said process reconciles a top-down forecast with a bottom-up forecast. 

19. A system as recited in daim 18, wherein said bottom-up forecast includes an expert based model. 

40 

20. A storage media, corrprising a recordation process reconciling production, sales and inventory of a supply chain. 

21. A dedsion support system, comprising: 

49 — =- 

a client comprising: 

dedsion support frames providing a view into production, sales and inventory of a supply chain, said 
frames integrating analytical models of a sippJy chain responsive to a view point of a business process, 
so said frames corrprising a supply management frame, a demand management frame, a vendor managed 

replenishment frame, a planning, sales and inventory frame and a distribution network frame; and 

a server comprising: 

55 a model engine, comprising: 

modeling processes analyzing the chain, said modeling processes comprising a component procure- 
ment policy development module, a finished goods distribution network design module, an aggregate 
production planning module, a finished goods inventory management module, a sales forecasting and 
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planning module, a market data analysis module and a vender managed replenishment module; and 
a demand and supply recondliation process reconciling production, sales and inventory by reconciling 
a topdown forecast with a bottom-up liorecadindudir^ an expert based model; 
a capacity process determining feasMhty of a capacity plan responsive to supply constraints; 

5 a replenishment process providing a vendor replenishment plan responsive to predicted sales and 

supply constraints said process reconciles a top<lown forecast wfth a bottonnjp forecast; 
a scenario management process providing scenarios tor comparison of management plans; 
a frame manager managing the execution of the modeling processes to provide information for said 
frames, said manager comprising a system integrator and a functional integrator; 

10 a database management system supplying database inform a t i on to the modeling processes and said 

frame manager; and 

a domain management process limiting data available to said frames responsive to a user selection. 
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Decision Support Thread 
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Specification of Decision Support Frame 



FIG. 7 
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High Level Model of an Equipment Repair Supply Chain and the Decision Processes 



FIG. 9 
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Data Flow for the Demand Management Frame 
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Process Flow of the Supply Management Frame 
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Promotion Calendar Main Display 
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The Options menu choices on the PSI screen 



Fl£61 



217 



EP0770967A2 




PSI Reconciliation Order Dialog Box 
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The main capacity checking dialog-box-^ The Options tab 
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The Production Resource tab 
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The Bill of Material tab 
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The Alternative Components Tab 
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Key Component Selection Dialog Box 
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